Die dem Artikel beigefügten Fotos verraten nichts darüber, was an QT5 neu ist. Im Gegenteil: Mit Ausnahme der Bilder-Galerie könnte es sich im Prinzip sogar noch um QT2 handeln.
Von Roadrunner123 am Fr, 30. November 2012 um 01:27 #
Ich auch - gerade, weil dort draussen noch Rechner stehen, die nen Core2Duo mit einer Intel-onboard-Grafikkarte laufen und da alles, was nur ansatzweise in Richtung OpenGL geht, absolut unbrauchbar ist und nicht jeder möchte sich dafür eine Grafikkarte kaufen (müssen); das macht sich bei 10 und mehr Rechnern doch bemerkbar.
In Qt5 ist die X11 Paint Engine - ohne Not - rausgeflogen und damit ist tatsächlich nur noch Softwarerendern drin. D.h. man fällt auf Linux Systemen auf das Niveau von Qt/Windows zurück. Also wenn man unter Linux hardwarebeschleunigte Graphik haben will, sollte man die Finger von Qt5 lassen - es sei denn man will tatsächlich mit dem neuen Qt Quick 2 arbeiten ( so viel zum Thema Geschwindigkeitsvorteile bzw. Kompatibilität ! )
Remote/X11 kann man mit dem Softwarerenderer natürlich komplett vergessen - aber das scheint ja eine Funktionalität zu sein, die ohnehin von den Entwicklern verschiedenster Projekte gerne zu Gunsten von Grafikeffekten negiert wird.
Leider kann man derzeit Qt Quick 2 Komponenten und QWidgets nicht vernünftig mischen ( im selben Top Level Fenster ). Ich hoffe das kommt mit Qt 5.1 - ansonsten kann ich mir nicht vorstellen wie man ein Desktop Projekt mit dem mehr wie unvollständigen Qt Quick 2 realisieren möchte.
Ab Qt 4.8 ist graphicssystem raster default weil es wesentlich schneller ist bei lokalen X11 Clients als native. Raster gibts weiterhin. Ansonsten OpenGL mit X11 oder Wayland was auch hervorragend mit QWidgets tut. Bei QML2 ist OpenGL Pflicht. Kannst aber auch weiter QML1 verwenden oder halt QML2 mit llvmpipe.
Wenn Du sowas wie ein Oszilloskop programmieren willst - also einfach ein langes Polygon ( pen width 0 ! ) mit hoher Bildwiederholrate zeichnen - kommen Dir mit Raster die Tränen. Für diesen Fall ist X11 um Faktoren schneller !
Es gibt natürlich Anwendungsfälle in denen Raster schneller sein kann ( z.B. auf meinem System das Füllen einer Fläche mit Gradienten ), aber in der Regel ist ein Hardware Renderer immer schneller als ein Softwarerenderer - lass Dir da nichts erzählen.
Bei normalen Anwendungen sind beide Alternativen lokal natürlich schnell genug, bei Remote/X11 kannst Du Dich dagegen mit dem Softwarerenderer an "fallenden Vorhängen" erfreuen. Wenn Du dann eine Anwendung mit einem graphischen Editor hast wird es ganz schnell unbedienbar, weil das Neuzeichnen mit den Mausbewegungen nicht mehr nachkommt.
Ich sitze in der Regel an einem Rechner mit Atom Prozessor und NVIDIA ION Grafik - also mit lausiger CPU aber in Relation halbwegs vernünftiger Grafikleistung. Da ist der Unterschied natürlich besonders signifikant.
Von ------------------------------ am Fr, 30. November 2012 um 16:56 #
Es gibt natürlich Anwendungsfälle in denen Raster schneller sein kann ( z.B. auf meinem System das Füllen einer Fläche mit Gradienten )
Nein =)
Qt benutzt für Gradienten intern immer die raster engine und schiebt das Ergebnis per XPutImage hoch. Je mehr putimages, desto mehr rountrips desto schlechter die performance.
Der nvidia blob gehört aber zu den Treibern mit brauchbarer [1] XRenderCreate*Gradient Unterstützung und ist dabei (je nach GPU um Größenordnungen schneller als das raster graphicssystem ...
[1] ... der Grund für den internen raster Zwang...
Ohne Dir im Allgemeinen widersprechen zu wollen - mein System ( zumindest die Version, mit der ich es damals probiert habe ) spricht da eine andere Sprache.
Mal davon abgesehen dass bestimmet Gradienten unter X11 nicht nicht korrekt funktionieren ( StretchToDeviceMode ) ist die Performance ein QPixmap mit einem Gradienten zu füllen ganz furchtbar. ( ~200 ms ! ). Ich bin sogar dazu übergegangen erst ein QImage zu erzeugen ( immer raster ) und es dann anschhließend in QPixmap zu konvertieren ( schlecht aber zumindest nicht mehr als ca 30 ms ).
Aber allgemeine Aussagen bzgl. Performance sind ohnehin recht fragwürdig ( selbst so ein Schnarcher wie Qt 4.0 wurde damals ja entsprechend verkauft ) , da sie prinzipiell vom Anwendungsfall abhängen.
In meinem Projekt ( http://qwt.sf.net ) gibt es zum Beispiel einen Modus in dem man inkrementell auf den Plot zeichnet - ein typischer Anwendungsfall für Live Charts. Mit X11 kann man das außerhalb von Paint Events mit einem direkten QPainter Befehl realisieren.
Ich behaupte mal diesen speziellen Anwendungsfall bekommt man mit den Szenengraph nicht ansatzweise so performant hin.
PS: wen es interessiert - ich habe gerade eine Bugfix Version von Qwt freigegeben.
Von ------------------------------ am Fr, 30. November 2012 um 18:47 #
wenn du ein qpixmap per qpainter/qbrush mit einem gradienten füllst läuft das intern über das raster graphicssytem - du mußt schon xrender nativ (auf dem handle) bemühen, resp. sein ergebnis mit XRenderComposite auf das handle blitten. die performance auf einer "richtigen" nvidia gpu lag (300 serie nicht getestet) mit dem blob lag dann knapp unter opengl gradienten.
insbesondere das erzeugen von 32bit qpixmaps aber auch alle qgradient operationen auf nativen qpixmaps sind aber grauslig (und waren noch schlimmer)
Von ------------------------------ am Sa, 1. Dezember 2012 um 14:56 #
"Jein"
Das Qt raster graphicssystem ist in einigen Belangen schneller als das native graphicssystem, weil das native graphicssystem in dem Zusammnenhang effektiv nicht zum Zuge kommt, ja.
Das Rendern per CPU in ein raster Backend ist aber (bei entsprechender Treiberunterstützung) trotzdem deutlich langsamer als XRender (man kommt nur eben nicht um nativen code herum) - je nach Performanceanforderung und Zielsystem kann sich das aber durchaus lohnen.
Ich habe an verschiedenen Orten Rechner mit P4 3GHz + Nvidia Geforce 6200 , AMD Sempron mit 1,2GHz onboard ati. Das ganze 3D-Geraffel suckt einfach nur. Für 2D sollte man auch nur 2D-Beschleunigung (das können alle Karten) verwenden.
Nun soll mir keiner kommen und sagen, dass das alles alte Rechner sind, das weiss ich selber. Es gibt aber genügend Einrichtungen, die auf solche Rechner angewiesen sind und nicht neue Rechner kaufen können. Ähnlich sieht es in ärmeren Ländern aus.
Allerdings muss ich sagen, dass KDE & Co. da auch schnell laufen sollte. KDE3 lief auf einem 500MHz Rechner mit 500MB RAM gut und schnell.
Ich würde sagen, dass 1GHz und 1 GB RAM sowie onboard-Grafikkarte mit 2D-Beschleunigung für normale Nutzung (keine Spiele) locker ausreichen muss.
> Dann nutz doch KDE3 Nutze ich auf meinem Arbeitsrechner (nicht langsam!) immernoch.
> http://www.trinitydesktop.org Hatte ich mir vor einer Weile angeschaut, aber ich hatte so einige Probleme. So bin ich erstmal bei Lenny (und 3.5.10) geblieben.
Ich warte ja immernoch, dass u.a. die Plasma-Leiste endlich wieder stapelbar wird, die größten KDE-Probleme sind nun langsam behoben.
Gerade eben mal KDE4.9.3 auf dem Testrechner ausprobiert (mit bestehender Konfig) und feststellen müssen, dass KMail meine IMAP-Mailkonten nicht mehr abholen mag (Passwort falsch, akonadi behauptet, er darf nicht auf KWallet zugreifen, was aber falsch ist). Das hat aber bis 4.8.x auf jeden Fall funktioniert.
Hier werden die Weichen für die nächsten 5-10 Jahre gestellt (siehe das Alter von Qt4). Qt5 wird in der Applikationswelt sicher einige Zeit brauchen, bevor es sich überhaupt durchsetzt.
Warum soll man da Rücksicht auf Hardware nehmen, die heute schon fast 10 Jahre alt ist? Keiner hindert dich daran Qt4 weiter zu verwenden. Aber für was neues, darf man dann bitte auch auf einem halbwegs aktuellen Technologiestand aufbauen.
Und der Umbruch geht nunmal am besten mit einer neuen Major-Version.
Ich auch - gerade, weil dort draussen noch Rechner stehen, die nen Core2Duo mit einer Intel-onboard-Grafikkarte laufen und da alles, was nur ansatzweise in Richtung OpenGL geht, absolut unbrauchbar ist
Für solche Sachen sollten auch Intel-Onboard-Chips vollkommen ausreichend sein. Beispielsweise funktioniert OpenGL-Compositing mit kwin auf meinem Netbook (Atom 270, 945GME-Chipsatz (mit GMA-950-Grafikchip) vollkommen zufriedenstellend.
[q]> Durch die Nutzung von Scenegraph, das mindestens Open GL ES 2.0 benötigt, versprechen sich die Entwickler Geschwindigkeitsvorteile.
Wenn ich das schon lese, kriege ich schon den Hass.[/q]
Zugegebenermaßen nicht die aktuellste Version, aber ES 2.0 ist derzeit einfach die am meisten verbreitete Variante.
Anwendungen, deren Bedürfnisse erst durch höhere Versionen oder OpenGL Desktop Versionen gedeckt werden, können diese möglicherweise direkt im Kontext eines Qt OpenGL Widgets benutzen.
> So verfolgen die Entwickler kein geringeres Ziel als die Etablierung einer neuen > Art der Erstellung von Anwendungen. Zwar wird es auch mit der neuen Version > möglich sein, mit C++ Anwendungen zu erstellen, doch wird der Schwerpunkt > darauf gelegt, mit Qt Quick zu entwickeln und C++ nur noch für Funktionsblöcke > einzusetzen.
QWidget mit C++ ist ausgereift und bestens benutzbar. Qt Quick sehe ich eher bei Effekthaschereien und mobilen Geräten.
Wenn man nun sagen würde, beides geht und der Entwickler kann sich die am besten passende Methode aussuchen, wäre das OK für mich. Aber die Aussage aus dem Artikel ist schon etwas komisch.
Mein Vermutung ist, dass die Berichterstattung noch nicht den Wechsel von Nokia zu Digia, bzw. die dadurch verursachte Änderung im Entwicklungsfokus vollzogen hat.
D.h. als journalistischer Beitrag werden Anmerkungen hinzugefügt, die nicht länger zutreffend sind oder nicht im selben Ausmaß zutreffend sind.
Vielleicht wird das nach dem 5.0 Release besser, wenn es einfacher ersichtlich ist, dass für die meisten Anwendungen und ihre Entwickler wenig Unterschied zwischen Qt4.8 und 5.0 sind, aber neue Möglichkeiten offenstehen bzw. Verbesserungen stattgefunden haben.
Immer die 4 in der Versionsnummer wird langsam langweilig.
Die dem Artikel beigefügten Fotos verraten nichts darüber, was an QT5 neu ist. Im Gegenteil: Mit Ausnahme der Bilder-Galerie könnte es sich im Prinzip sogar noch um QT2 handeln.
Der Artikel kratzt auch nur an der Oberfläche. Für weiterführende Informationen zu deinem Interessengebiet halt selber Schlau machen.
Eine Übersicht neuer Features
http://qt-project.org/wiki/Qt-5Features#29fa2c2d59f7ad466f65f835efb636d0
Zu QML2 und Scenegraph
http://blog.qt.digia.com/blog/2011/05/31/qml-scene-graph-in-master/
Ansonsten google.
Du meinst "Digia" und "das Qt Projekt", nicht "Trolltech" und "Qt" oder?
> Durch die Nutzung von Scenegraph, das mindestens Open GL ES 2.0 benötigt, versprechen sich die Entwickler Geschwindigkeitsvorteile.
Wenn ich das schon lese, kriege ich schon den Hass.
Ich auch - gerade, weil dort draussen noch Rechner stehen, die nen Core2Duo mit einer Intel-onboard-Grafikkarte
laufen und da alles, was nur ansatzweise in Richtung OpenGL geht, absolut unbrauchbar ist und nicht jeder
möchte sich dafür eine Grafikkarte kaufen (müssen); das macht sich bei 10 und mehr Rechnern doch bemerkbar.
Kannst doch QWidget's verwenden. Die haben kaum bis keine 3D Sachen Animation, usw. und entsprechend schnell gehts sogar mit purem Softwarerendering.
In Qt5 ist die X11 Paint Engine - ohne Not - rausgeflogen und damit ist tatsächlich nur noch Softwarerendern drin. D.h. man fällt auf Linux Systemen auf das Niveau von Qt/Windows zurück. Also wenn man unter Linux hardwarebeschleunigte Graphik haben will, sollte man die Finger von Qt5 lassen - es sei denn man will tatsächlich mit dem neuen Qt Quick 2 arbeiten ( so viel zum Thema Geschwindigkeitsvorteile bzw. Kompatibilität ! )
Remote/X11 kann man mit dem Softwarerenderer natürlich komplett vergessen - aber das scheint ja eine Funktionalität zu sein, die ohnehin von den Entwicklern verschiedenster Projekte gerne zu Gunsten von Grafikeffekten negiert wird.
Leider kann man derzeit Qt Quick 2 Komponenten und QWidgets nicht vernünftig mischen ( im selben Top Level Fenster ). Ich hoffe das kommt mit Qt 5.1 - ansonsten kann ich mir nicht vorstellen wie man ein Desktop Projekt mit dem mehr wie unvollständigen Qt Quick 2 realisieren möchte.
Ab Qt 4.8 ist graphicssystem raster default weil es wesentlich schneller ist bei lokalen X11 Clients als native. Raster gibts weiterhin. Ansonsten OpenGL mit X11 oder Wayland was auch hervorragend mit QWidgets tut. Bei QML2 ist OpenGL Pflicht. Kannst aber auch weiter QML1 verwenden oder halt QML2 mit llvmpipe.
> QML2 mit llvmpipe.
Das will keiner.
Wenn Du sowas wie ein Oszilloskop programmieren willst - also einfach ein langes Polygon ( pen width 0 ! ) mit hoher Bildwiederholrate zeichnen - kommen Dir mit Raster die Tränen. Für diesen Fall ist X11 um Faktoren schneller !
Es gibt natürlich Anwendungsfälle in denen Raster schneller sein kann ( z.B. auf meinem System das Füllen einer Fläche mit Gradienten ), aber in der Regel ist ein Hardware Renderer immer schneller als ein Softwarerenderer - lass Dir da nichts erzählen.
Bei normalen Anwendungen sind beide Alternativen lokal natürlich schnell genug, bei Remote/X11 kannst Du Dich dagegen mit dem Softwarerenderer an "fallenden Vorhängen" erfreuen. Wenn Du dann eine Anwendung mit einem graphischen Editor hast wird es ganz schnell unbedienbar, weil das Neuzeichnen mit den Mausbewegungen nicht mehr nachkommt.
Ich sitze in der Regel an einem Rechner mit Atom Prozessor und NVIDIA ION Grafik - also mit lausiger CPU aber in Relation halbwegs vernünftiger Grafikleistung. Da ist der Unterschied natürlich besonders signifikant.
Nein =)
Qt benutzt für Gradienten intern immer die raster engine und schiebt das Ergebnis per XPutImage hoch. Je mehr putimages, desto mehr rountrips desto schlechter die performance.
Der nvidia blob gehört aber zu den Treibern mit brauchbarer [1] XRenderCreate*Gradient Unterstützung und ist dabei (je nach GPU
um Größenordnungen schneller als das raster graphicssystem ...
[1] ... der Grund für den internen raster Zwang...
Ohne Dir im Allgemeinen widersprechen zu wollen - mein System ( zumindest die Version, mit der ich es damals probiert habe ) spricht da eine andere Sprache.
Mal davon abgesehen dass bestimmet Gradienten unter X11 nicht nicht korrekt funktionieren ( StretchToDeviceMode ) ist die Performance ein QPixmap mit einem Gradienten zu füllen ganz furchtbar. ( ~200 ms ! ). Ich bin sogar dazu übergegangen erst ein QImage zu erzeugen ( immer raster ) und es dann anschhließend in QPixmap zu konvertieren ( schlecht aber zumindest nicht mehr als ca 30 ms ).
Aber allgemeine Aussagen bzgl. Performance sind ohnehin recht fragwürdig ( selbst so ein Schnarcher wie Qt 4.0 wurde damals ja entsprechend verkauft ) , da sie prinzipiell vom Anwendungsfall abhängen.
In meinem Projekt ( http://qwt.sf.net ) gibt es zum Beispiel einen Modus in dem man inkrementell auf den Plot zeichnet - ein typischer Anwendungsfall für Live Charts. Mit X11 kann man das außerhalb von Paint Events mit einem direkten QPainter Befehl realisieren.
Ich behaupte mal diesen speziellen Anwendungsfall bekommt man mit den Szenengraph nicht ansatzweise so performant hin.
PS: wen es interessiert - ich habe gerade eine Bugfix Version von Qwt freigegeben.
wenn du ein qpixmap per qpainter/qbrush mit einem gradienten füllst läuft das intern über das raster graphicssytem - du mußt schon xrender nativ (auf dem handle) bemühen, resp. sein ergebnis mit XRenderComposite auf das handle blitten.
die performance auf einer "richtigen" nvidia gpu lag (300 serie nicht getestet) mit dem blob lag dann knapp unter opengl gradienten.
insbesondere das erzeugen von 32bit qpixmaps aber auch alle qgradient operationen auf nativen qpixmaps sind aber grauslig (und waren noch schlimmer)
Womit Dein "Nein von oben dann doch zu einem "Genau" wird.
"Jein"
Das Qt raster graphicssystem ist in einigen Belangen schneller als das native graphicssystem, weil das native graphicssystem in dem Zusammnenhang effektiv nicht zum Zuge kommt, ja.
Das Rendern per CPU in ein raster Backend ist aber (bei entsprechender Treiberunterstützung) trotzdem deutlich langsamer als XRender (man kommt nur eben nicht um nativen code herum) - je nach Performanceanforderung und Zielsystem kann sich das aber durchaus lohnen.
Ich habe an verschiedenen Orten Rechner mit P4 3GHz + Nvidia Geforce 6200 , AMD Sempron mit 1,2GHz onboard ati. Das ganze 3D-Geraffel suckt einfach nur. Für 2D sollte man auch nur 2D-Beschleunigung (das können alle Karten) verwenden.
Nun soll mir keiner kommen und sagen, dass das alles alte Rechner sind, das weiss ich selber. Es gibt aber genügend Einrichtungen, die auf solche Rechner angewiesen sind und nicht neue Rechner kaufen können. Ähnlich sieht es in ärmeren Ländern aus.
Allerdings muss ich sagen, dass KDE & Co. da auch schnell laufen sollte. KDE3 lief auf einem 500MHz Rechner mit 500MB RAM gut und schnell.
Ich würde sagen, dass 1GHz und 1 GB RAM sowie onboard-Grafikkarte mit 2D-Beschleunigung für normale Nutzung (keine Spiele) locker ausreichen muss.
Sehe ich auch so, Problem ist das die wenigsten Entwickler solche PCs nutzen, ansonsten würde es "locker ausreichen"
Man muß wohl realisieren das KDE4 nichts für "ältere" PCs ist.
Dann nutz doch KDE3
http://www.trinitydesktop.org/
> Dann nutz doch KDE3
Nutze ich auf meinem Arbeitsrechner (nicht langsam!) immernoch.
> http://www.trinitydesktop.org
Hatte ich mir vor einer Weile angeschaut, aber ich hatte so einige Probleme. So bin ich erstmal bei Lenny (und 3.5.10) geblieben.
Ich warte ja immernoch, dass u.a. die Plasma-Leiste endlich wieder stapelbar wird, die größten KDE-Probleme sind nun langsam behoben.
Gerade eben mal KDE4.9.3 auf dem Testrechner ausprobiert (mit bestehender Konfig) und feststellen müssen, dass KMail meine IMAP-Mailkonten nicht mehr abholen mag (Passwort falsch, akonadi behauptet, er darf nicht auf KWallet zugreifen, was aber falsch ist). Das hat aber bis 4.8.x auf jeden Fall funktioniert.
Ich bin wirklich froh, das stabile KDE3 zu nutzen
Hier werden die Weichen für die nächsten 5-10 Jahre gestellt (siehe das Alter von Qt4). Qt5 wird in der Applikationswelt sicher einige Zeit brauchen, bevor es sich überhaupt durchsetzt.
Warum soll man da Rücksicht auf Hardware nehmen, die heute schon fast 10 Jahre alt ist? Keiner hindert dich daran Qt4 weiter zu verwenden. Aber für was neues, darf man dann bitte auch auf einem halbwegs aktuellen Technologiestand aufbauen.
Und der Umbruch geht nunmal am besten mit einer neuen Major-Version.
[q]> Durch die Nutzung von Scenegraph, das mindestens Open GL ES 2.0 benötigt, versprechen sich die Entwickler Geschwindigkeitsvorteile.
Wenn ich das schon lese, kriege ich schon den Hass.[/q]
Zugegebenermaßen nicht die aktuellste Version, aber ES 2.0 ist derzeit einfach die am meisten verbreitete Variante.
Anwendungen, deren Bedürfnisse erst durch höhere Versionen oder OpenGL Desktop Versionen gedeckt werden, können diese möglicherweise direkt im Kontext eines Qt OpenGL Widgets benutzen.
> So verfolgen die Entwickler kein geringeres Ziel als die Etablierung einer neuen
> Art der Erstellung von Anwendungen. Zwar wird es auch mit der neuen Version
> möglich sein, mit C++ Anwendungen zu erstellen, doch wird der Schwerpunkt
> darauf gelegt, mit Qt Quick zu entwickeln und C++ nur noch für Funktionsblöcke
> einzusetzen.
QWidget mit C++ ist ausgereift und bestens benutzbar.
Qt Quick sehe ich eher bei Effekthaschereien und mobilen Geräten.
Wenn man nun sagen würde, beides geht und der Entwickler kann sich die am besten passende Methode aussuchen, wäre das OK für mich.
Aber die Aussage aus dem Artikel ist schon etwas komisch.
Mein Vermutung ist, dass die Berichterstattung noch nicht den Wechsel von Nokia zu Digia, bzw. die dadurch verursachte Änderung im Entwicklungsfokus vollzogen hat.
D.h. als journalistischer Beitrag werden Anmerkungen hinzugefügt, die nicht länger zutreffend sind oder nicht im selben Ausmaß zutreffend sind.
Vielleicht wird das nach dem 5.0 Release besser, wenn es einfacher ersichtlich ist, dass für die meisten Anwendungen und ihre Entwickler wenig Unterschied zwischen Qt4.8 und 5.0 sind, aber neue Möglichkeiten offenstehen bzw. Verbesserungen stattgefunden haben.
Und, wird es mit LLVM/CLang compilieren?
Ist clang nicht der neue Standard-Compiler von OS X?