Hallo @all
Ich muss zugeben, dass ich mich noch nicht wirklich viel mit der 4.6 Beta beschäftigt habe.
Meine Frage zielt aber sowieso auf persönliche Erfahrungen, dass CanvasGadget betreffend hin.
Was das Gadget macht und wofür es da ist, ist mir schon klar. Die Frage ist, welche Vorteile
bietet es mir im Gegensatz zum ImageGadget?
Gerade in Richtung Performanz?!? Ist das Drawing / bzw. das RePaint Verhalten da anders?
Ich will halt verschiedene GUI Elemente selber gestalten. Bis dato habe ich das immer über
das ImageGadget gemacht, was auch gut funktioniert hat. Nun würde ich halt gerne auf das Canvas Gadget
umsteigen, wenn es Sinn macht.
Gruß, Morty
CanvasGadget vs ImageGadget
- ts-soft
- Beiträge: 22292
- Registriert: 08.09.2004 00:57
- Computerausstattung: Mainboard: MSI 970A-G43
CPU: AMD FX-6300 Six-Core Processor
GraKa: GeForce GTX 750 Ti, 2 GB
Memory: 16 GB DDR3-1600 - Dual Channel - Wohnort: Berlin
Re: CanvasGadget vs ImageGadget
CanvasGadget ist doppelt gepuffert, Du brauchst also keinen Umweg über ein mit CreateImage erstelltem
Image gehen, desweiteren stehen Dir ja so ziemlich alle Ereignisse zur Verfügung, die Du sonst nur per API
ermitteln kannst.
Image gehen, desweiteren stehen Dir ja so ziemlich alle Ereignisse zur Verfügung, die Du sonst nur per API
ermitteln kannst.
PureBasic 5.73 LTS | SpiderBasic 2.30 | Windows 10 Pro (x64) | Linux Mint 20.1 (x64)
Nutella hat nur sehr wenig Vitamine. Deswegen muss man davon relativ viel essen.

Nutella hat nur sehr wenig Vitamine. Deswegen muss man davon relativ viel essen.

Re: CanvasGadget vs ImageGadget
Okay, das sind Vorteile, was das Handling an geht.
Bleibt halt noch die Frage, ob es in der Performanz schneller ist, als ein ImageGadget.
Ich gehe mal etwas mehr ins Detail.
Ich habe ein Programm, welches in der Auflösung 1280 x 720 läuft.
Bis jetzt realisiere ich alles über verschiedene ImageGadgets (aufgeteilt in verschiedene Bereiche).
Das läuft auch ziemlich gut. Jetzt will ich aber die komplette GUI überarbeiten und auch mit
kleinen Animationen alles homogener erscheinen lassen.
Daher ist mein Anliegen aus den x Imagegadgets -> 1 CanvasGadget zu machen. Das lohnt sich aber nur,
wenn ich dann keinen all zu großen Einbruch in der Performanz kriege. Klar, dieser wird da sein.
Aber ihr kennt das doch auch. Ich will nicht 3 Tage rein investieren, um dann die Ernüchterung zu kriegen
Gruß, Morty
Bleibt halt noch die Frage, ob es in der Performanz schneller ist, als ein ImageGadget.
Ich gehe mal etwas mehr ins Detail.
Ich habe ein Programm, welches in der Auflösung 1280 x 720 läuft.
Bis jetzt realisiere ich alles über verschiedene ImageGadgets (aufgeteilt in verschiedene Bereiche).
Das läuft auch ziemlich gut. Jetzt will ich aber die komplette GUI überarbeiten und auch mit
kleinen Animationen alles homogener erscheinen lassen.
Daher ist mein Anliegen aus den x Imagegadgets -> 1 CanvasGadget zu machen. Das lohnt sich aber nur,
wenn ich dann keinen all zu großen Einbruch in der Performanz kriege. Klar, dieser wird da sein.
Aber ihr kennt das doch auch. Ich will nicht 3 Tage rein investieren, um dann die Ernüchterung zu kriegen

Gruß, Morty
Re: CanvasGadget vs ImageGadget
Ich hab gerade kein purebasic hier um das zu machen, aber der beste weg diese frage zu beantworten wäre ein kleiner benchmark.
Bastel ein Programm, dass über imagegadgets ein paar tausend Zeichenoperationen durchführt und anzeigt, mach dass selbe im canvasgadget und miss bei beiden die zeit mit GetTickCount_(). Dann kannst du leicht sehen welches schneller ist. Ich würde aber auf jeden fall das canvas gadget nutzen, schon wegen der api Unabhängigkeit und der damit verbundenen leichteren Portierung.
Bastel ein Programm, dass über imagegadgets ein paar tausend Zeichenoperationen durchführt und anzeigt, mach dass selbe im canvasgadget und miss bei beiden die zeit mit GetTickCount_(). Dann kannst du leicht sehen welches schneller ist. Ich würde aber auf jeden fall das canvas gadget nutzen, schon wegen der api Unabhängigkeit und der damit verbundenen leichteren Portierung.
Re: CanvasGadget vs ImageGadget
Die Performance scheint in etwa gleich. Hab mich aber entschieden
weiterhin mit dem Imagegadget zu arbeiten, da ich eh an die DIB's
ran muss..
weiterhin mit dem Imagegadget zu arbeiten, da ich eh an die DIB's
ran muss..
"Papa, ich laufe schneller - dann ist es nicht so weit."
Re: CanvasGadget vs ImageGadget
Ich versuche es erstmal mit dem CanvasGadget umzusetzen. Mal sehen wie weit ich komme.
Mal grundsätzlich. Ich komme ja aus dem Musik - Bereich. Und gerade die ganzen großen DAW Programme (Cubase, Nuendo, Reaper, ...) glänzen ja mit einer eigenen GUI.
Ich kann mir gerade im Hinblick auf Performanz schlecht vorstellen, dass das alles via Images oder ähnliches realisiert wird.
Oder steckt da auch nur "ganz gutes" Handling im Hintergrund?
Gruß, Morty
Mal grundsätzlich. Ich komme ja aus dem Musik - Bereich. Und gerade die ganzen großen DAW Programme (Cubase, Nuendo, Reaper, ...) glänzen ja mit einer eigenen GUI.
Ich kann mir gerade im Hinblick auf Performanz schlecht vorstellen, dass das alles via Images oder ähnliches realisiert wird.
Oder steckt da auch nur "ganz gutes" Handling im Hintergrund?
Gruß, Morty
Re: CanvasGadget vs ImageGadget
Selbst auf einem Netbook sollte es kein Problem mehr sein solche GUIs mit images umzusetzen. Bei den versierteren Windows API Profis ist es wohl auch üblich die Zeichenroutinen von Standard Windows GUI Elementen zu überschreiben oder eigene umzusetzen, die analog zu den Windowseigenen funktionieren. API seitig ist ein GUI Element ein eigenes Fenster mit besonderen Eigenschaften.
Ich würde aber einfach bei Images oder Canvas bleiben, dass ist deutlich einfacher und hat den Vorteil, dass es portierbar ist/in einer portierbaren Art und weise gemacht werden kann.
Wenn es Geschwindigkeitsprobleme gibt, dann liegt das meistens an konzeptionellen Fehlern. Beliebt ist zum Beispiel der Fehler, bei einer langen graphartigen anzeige, zum Beispiel bei der Repräsentation einer langen Tondatei, die Repräsentation der gesamten datei zu rendern, statt nur dem Teil der auch wirklich sichtbar ist. Wenn du solche Fehler vermeidest, dann sollte es eigentlich keine Probleme geben.
Ich würde aber einfach bei Images oder Canvas bleiben, dass ist deutlich einfacher und hat den Vorteil, dass es portierbar ist/in einer portierbaren Art und weise gemacht werden kann.
Wenn es Geschwindigkeitsprobleme gibt, dann liegt das meistens an konzeptionellen Fehlern. Beliebt ist zum Beispiel der Fehler, bei einer langen graphartigen anzeige, zum Beispiel bei der Repräsentation einer langen Tondatei, die Repräsentation der gesamten datei zu rendern, statt nur dem Teil der auch wirklich sichtbar ist. Wenn du solche Fehler vermeidest, dann sollte es eigentlich keine Probleme geben.
Re: CanvasGadget vs ImageGadget
Stimmt, aber gerade was sowas angeht passe ich schon immer ziemlich gut auf
Das auch wirklich nur das gezeichnet wird, was im sichtbaren Bereich ist, bzw. von Relevanz.
Nur nebenbei, nicht damit ein falscher Anschein erweckt wird. Ich will keine Audiosoftware schreiben. Das diente nur als Beispiel für grafisch besonders aufwändige GUIs.
Gruß, Morty

Nur nebenbei, nicht damit ein falscher Anschein erweckt wird. Ich will keine Audiosoftware schreiben. Das diente nur als Beispiel für grafisch besonders aufwändige GUIs.
Gruß, Morty