Performance SWT ???

[mede]

Ich benütze in meinem GUI eine eigene Tabelle mit SWT Composites welche wiederum Text und Bilder enthalten.
Da ich mehrere 100 dieser Composites verwende frage ich mich ob es besser währe Text und Bilder selber in einem PaintListener mit Hilfe des GC zu zeichnen, anstelle dafür Labels zu verwenden, welche mit einem null Layout im Composite positioniert sind ???

Ist ein merklicher Unterschied (Performance, Resources) vorhanden ob man Text und Bild mit einem Label oder direkt über die GC zeichnet ???


-----------------------------Variante mit Subelemte (LABEL)
..................................
COMPOSITE................
------------.... ----------
| LABEL | ... | LABEL |
----------- .... ---------
.................. -----------
...................| LABEL |
...................-----------
..................................

..................................
COMPOSITE................
------------.... ----------
| LABEL | ... | LABEL |
----------- .... ---------
.................. -----------
...................| LABEL |
...................-----------
..................................

... (mehrere 100 Wiederholungen)

-------------------------------Variante mit PaintListener
........................................
COMPOSITE......................
gc.drawImage gc.drawText
.......................................
..................... gc.drawtext
.......................................
.......................................

........................................
COMPOSITE......................
gc.drawImage gc.drawText
.......................................
..................... gc.drawtext
.......................................
.......................................

... (mehrere 100 Wiederholungen)

WELCHE VARIANTE IST BESSER (SCHNELLER) ???

 

[mikachu]

WELCHE VARIANTE IST BESSER (SCHNELLER) ???

ausprobieren...

 

[byte]

Werden denn zur Laufzeit immer alle Daten aktualisiert oder jeweils immer nur ein Teil der Daten? Letzteres ist natürlich beim Zeichnen über den GC etwas schwieriger umzusetzen. Dann müsstest Du Dir einen geeigneten Mechanismus überlegen, wie Du immer nur die Teile im Canvas neu zeichnest, die sich geändert haben. Prinzipiell ist es natürlich möglich. Auf jeden Fall darauf achten, nicht direkt aufs Canvas zu zeichnen, sondern zunächst in ein Image und danach das Image aufs Canvas (Double Buffering). Wenn Du jedes Mal alles neu zeichnest, ist es fraglich, ob das dann noch performanter ist.

Ich würds erstmal mit Widgets lösen (weils schneller umzusetzen ist) und falls das nicht performant genug ist, kannst Du immernoch den alternativen Weg über Canvas und GC gehen.


Edit: Grade gesehen, dass Du auf die Composites zeichnen willst. Ist natürlich auch eine Lösung, aber ich denke, das wird vielleicht sogar langsamer sein als mit Labels. Aber am performantesten wirds sein, ein großes Canvas zu nehmen.

 

[mede]

Es werden immer alle Daten eines Composite verändert. Somit muss nicht teilweise neu gezeichnet werden.

jedoch habe ich Funktionen implementiert welche das Bild und das Label zum Teil bei MouseOver Aktionen verändert. vergrösser, verschiebt. Dies währe dann ein wenig schwierig wenn man es selber zeichnen müsste. Bzw müsste wiederum das ganze Composite (od. Canvas) neu gezeichnet werden.

Die Lösung mit den Labels im Composite die ich jetzt verwende ist auch kritisch, da so viele Componente erzeugt werden, dass zum Teil das Maximum erreicht wird !

Hier kann man sich ein Bild davon machen was ich probiere:
http://www.aacm.ch/mede/simplon/

 

[Wildcard]

Die Lösung mit den Labels im Composite die ich jetzt verwende ist auch kritisch, da so viele Componente erzeugt werden, dass zum Teil das Maximum erreicht wird !

Oh je....
Ich sehe schon wo das hinführt.
Selbst ohne die Labels wird das Problem aber nicht verschwinden, den da sind immer noch tausende von Bildern.
Mit Swing wärst du definitiv besser beraten gewesen. Spätestens wenn du anfangen musst Images beim Scrollen zu disposen... :autsch:

 

[WieselAc]

Ich hoffe du hast dir eine "ImageRegistry" geschrieben und du benutzt ImageDescriptor sonst gehst du ganz shcnell baden.

 

[mede]

SWING denke nicht das man mit SWING ein solches GUI performant hinkriegt, auf jedenfall nicht auf einem alten G3 iBook ... aber diese Diskusion währe für einen anderen Thread.

Hm ich habe etwas wie eine Cover (Image) Cache, aber der verhindert nur, dass ein Bild nicht mehrmals geladen wird. Ich hatte schon ca. 300 Covers geladen was Problemlos funktionierte... Muss ich etwas beachten, wenn ich so viele Instanzen von Bildern verwende ?

 

[Wildcard]

Ich hoffe du hast dir eine "ImageRegistry" geschrieben und du benutzt ImageDescriptor sonst gehst du ganz shcnell baden.

Das wird hier wenig nutzen, da diese Images mit Sicherheit alle unterschiedlich sind.

SWING icon_wink.gif denke nicht das man mit SWING ein solches GUI performant hinkriegt, auf jedenfall nicht auf einem alten G3 iBook ... aber diese Diskusion währe für einen anderen Thread.

Mit Sicherheit. Swing ist nicht langsamer als SWT.

Muss ich etwas beachten, wenn ich so viele Instanzen von Bildern verwende ?

Auch für die Bilder musst du native Resourcen allokieren, die dir irgendwann auch einfach ausgehen können.

 

[mede]

Ok zugegeben Swing ist nur langsam, wenn man es schlech programmiert.
Ich habe mich für SWT entschieden, weil ich auch damit einmal etwas erstellen wollte. In der Schule und im Job
habe ich bis anhin für Java nur mit Swing gearbeitet.

Ich versuche kaum vorgegebene Komponente zu benütze, Buttons und Menus habe ich mit Images Implementiert und die Listen und Tabellen versuche ich auch selbt zu zeichnen. Deshalb währe wahrscheinlich kaum ein Performance unterschied zu Swing, sofern man sich bei Swing auch mit einfachen Komponenten begnügt.

Ok dies mit den Resourcen muss ich wohl noch etwas genauer betrachten und mein Konzept ein wenig umbauen. Ich finde es jedoch interessant, wenn man sich um solche Probleme selber kümmer muss, und diese nicht vom Framework übernommen werden.

Deshalb habe ich während dem Studium auch eine eigene OpenGL Engine geschrieben