@"Chefentwickler"
-
Chefentwickler schrieb:
Aber eines haben alle Java-GUIs gemein: Sie sind SAU LAHM!!!
azureus ist java und hat ne GTK-Oberfläche, die ist nicht sau-lahm.
-
Aber eines haben alle Java-Swing-GUIs gemein: Sie sind SAU LAHM!!!
-
2 schrieb:
Aber eines haben alle Java-Swing-GUIs gemein: Sie sind SAU LAHM!!!
Ja? Weiß nicht. Kannst du da mal quantitative Angaben machen? Zum Beispiel durch nen Benchmark, in dem Swing mit anderen GUI-Toolkits verglichen wird?
Zumindest bei meinem Programm kann ich eindeutig sagen, dass das Problem nicht die Geschwindigkeit des GUI-Toolkits ist. Wenn man Datensätze darstellen will, die teilweise bis zu 170MB groß sind, dann kommen Performanceprobleme sicherlich nicht dadurch, dass irgendein Label doppelt so lange zum Zeichnen braucht als bei nem anderen Toolkit.
-
QT ist außerdem auch saulahm...
Wenn wir schon beim bashen sind
-
Ringding schrieb:
QT ist außerdem auch saulahm...
Wenn wir schon beim bashen sind
QT ist aber cool
-
GUI-Systeme sind fast nie so lahm, dass ein kümmerlicher Mensch das sehen würde. Der Hauptpunkt ist hier immer die gefühlte Performance: Man drückt nen Knopf und es dauert ne Sekunde, bis das Ergebnis da ist. Das kann man durch rumblinkendes Klickibunti ganz erheblich verhindern.
Wenn ich in der Windows-Systemsteuerung bei den Darstellungsoptionen was verändere und auf OK drücke, bleibt der Button auch für eine Sekunde lang eingedrückt. Ich würde allerdings nicht vermuten, dass es so lange dauert, den Button wieder grafisch hochschnellen zu lassen.
In Eclipse wenn ich zum ersten mal nen Rechtsklick im Code-Editor mache, dauert es ne Sekunde bis das Menü da ist. Das liegt auch nicht am lahmen GUI, sondern daran, dass die entsprechenden Plugins zum ersten mal geladen werden (von der Platte!).
-
Fast alle Java-GUI-Programmierer sind schlecht.
-
Optimizer schrieb:
GUI-Systeme sind fast nie so lahm, dass ein kümmerlicher Mensch das sehen würde.
In den meisten Fällen stimmt das. Aber beim Scrollen in Listen/Trees o.ä. ganz und gar nicht. Da macht es einen großen Unterschied, ob das Ding mit der Samplerate der Maus mitkommt oder ob nur 10-20 fps gezeichnet werden, wie es bei QT üblicherweise der Fall ist.
-
Ringding schrieb:
QT ist außerdem auch saulahm...
unter windows?
-
DrGreenthumb schrieb:
unter windows?
Ja.
Unter Linux ist alles saulahm (was mit GUIs zu tun hat, meine ich...).
-
Ringding schrieb:
DrGreenthumb schrieb:
unter windows?
Ja.
Unter Linux ist alles saulahm (was mit GUIs zu tun hat, meine ich...).
Troll oder ernst?
-
sicher? schrieb:
Troll oder ernst?
Troll.
-
Ernst.
Zeig mir mal irgendwas grafisches, das unter Linux wirklich zügig auf einer 300MHz-CPU läuft. Unter Windows absolut kein Problem.
-
Das stimmt nur teilweise fazit.
Schau dir mal beliebige Programme an: wenn du auf irgendetwas klickst, gibts erstmal ein graphischer Gimmik, dann darf man ein paar (Milli)-Sekunden warten, dann erst kommt das Resultat.
"Warten" ist also ganz natürlich (und man ist sich auch daran gewöhnt).
Die Frage ist nur "wann" darf man den Benutzer warten lassen? Sicherlich nicht dann, wenn er gerade in Höchstform ist, und auf einen Knopf gedrückt hat. Dann muss *irgendwas* passieren. Was, ist hingegen total egal.Ich sitze gerade an einem Programm das Interviews auswerten soll. Jede Auswertung (=alles mit allem nach gewissen Kriterien vergleichen) benötigt rund 2-4 Sekunden. Da ich einen eigenen Thread für diese Berechnungen benutze, können Buttons und Menüs gleich nach einem Klick zurück in die Ursprungsgestalt springen (=es passiert was). Der Effekt: das Programm wirkt extrem schnell obwohl der Benutzer sekundenlang warten muss.
Besonders Anfänger, auch auch manch "Fortegschrittener", kennen diese (psychologischen und programmtechnischen) Tricks nicht. Von diesen Leuten kommen dann die Programme mit den trägen Oberflächen. Insofern sind sie nicht "schlecht", sondern schlicht und einfach "unerfahren".
-
nman schrieb:
sicher? schrieb:
Troll oder ernst?
Troll.
Du kannst gern in meinem Profil auf "Alle Posts von Ringding anzeigen" klicken und mal ein paar Seiten durchbrowsen. Dann siehst du, dass ich normalerweise sehr genau weiß, wovon ich schreibe.
-
Ach Blödsinn. Ich hatte lange Zeit eine 300MHz CPU in meinem Rechner und hatte damit nie Performance-Probleme.
-
Ringding schrieb:
Zeig mir mal irgendwas grafisches, das unter Linux wirklich zügig auf einer 300MHz-CPU läuft. Unter Windows absolut kein Problem.
Da gebe ich dir recht.
Aber während Java-GUIs auf meinem 3.4ghz-Athlon mit 1gb RAM _heute_ immer noch sehr lahm sind, läuft QT da absolut flüssig. Also so macht der Vergleich wenig Sinn.
-
genau, Greenthumb. man schaue sich nur mal Eclipse an, das braucht mehr als so manches Spiel
-
Könnte auch daran liegen, das es wirklich viel macht. Code während des Editierens compileren -> Fehler anzeigen...
-
DrGreenthumb schrieb:
Ringding schrieb:
Zeig mir mal irgendwas grafisches, das unter Linux wirklich zügig auf einer 300MHz-CPU läuft. Unter Windows absolut kein Problem.
Da gebe ich dir recht.
Das ist doch alles nur eine Frage des Arbeitsspeichers. 300MHz-Rechner haben normalerweise auch nur wenig Arbeitssspeicher. Und so ein primitives Betriebssystem wie Windows 98 (war etwa zur gleichen Zeit aktuell wie P2-300-Rechner beim MediaMarkt) kommt mit richtig wenig RAM naturgemäß besser aus, als ein komplexeres und moderneres Betriebssystem wie GNU/Linux.