PureBoard

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 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.

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

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.

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..

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

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.

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