@"Chefentwickler"
-
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!