@"Chefentwickler"
-
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.
-
Ringding schrieb:
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.
Du hast dich mit dem "üblicherweise" zwar geschickt abgesichert, aber wenn ich mir den Opera Browser anschaue, kommen mir ernsthafte Zweifel an deiner Behauptung.
// edit:
Ja ich weiß, schon wieder Opera. Aber wenn er nun mal in Qt geschrieben ist und ganz schrecklich toll scrollen kann
-
Ringding schrieb:
Ernst.
Zeig mir mal irgendwas grafisches, das unter Linux wirklich zügig auf einer 300MHz-CPU läuft. Unter Windows absolut kein Problem.
moagg. opera (mit "windows-style"). und das sogar auf einem 233er.
-
Hmm, jetzt habt ihr mich neugierig gemacht...
Ich vermute jetzt einfach mal ganz frech, dass sie sich für das Scrollen wohl eine eigene Lösung/Workaround einfallen lassen haben.
-
Scrollen ist schon ein Punkt, wo es vielleicht auch objektiv auf die Geschwindigkeit des GUI-Toolkits ankommt. Das gebe ich gerne zu. Trotzdem hat man hier aber auch unabhängig vom Toolkit gute Möglichkeiten zu optimieren, die erst dann nicht mehr ausreichend, wenn das Toolkit wirklich krass langsam ist. Wenn es viel zu scrollen gibt, darf man beispielsweise nur das wirklich sichtbare jedesmal neu darstellen.
Swing ist auf Grund der Art, wie es implementiert ist, im Moment relativ langsam in der Darstellung. Scrollen geht bei mir aber immer mega-flüssig, weil es den sichtbaren Bereich gut ausschneidet. Länger als ein paar hundertstel Sekunden malt selbst Swing nicht, wenn man es richtig macht. Und das sieht ein normaler Mensch einfach nicht. :xmas1:Umgekehrt kann man auch in einigen Eclipse-Dialogen (die ja die schnellen nativen Widgets nutzen) sehr gut sehen, dass sie träge erscheinen. Ein GUI muss in erster Linie "responsive" sein, nicht schnell. Ich behaupte also immer noch, dass die meisten Performance-Probleme bei GUIs in der falschen Benutzung des Toolkits liegen.
-
@gregor: danke!