H/W-Beschleunigung für die Toolkits wäre mal wichtiger.

[Nasenbaer]

Vielleicht liege ich ja falsch, bzw. ziehe die falschen Schlüsse (dann korrigiert mich), aber wenn man bei GTK- und QT-Anwendungen die Fenster skaliert und darum deren Inhalte neu gezeichnet werden müssen, dann ist das immer noch laggy.
Z.B. wenn eine Tabelle dann neu gezeichnet wird oder man eine Multi-Fenster-Anwendung hat wie Eclipse.

Also das Fenster als als ganzes verschieben geht schnell und zwischen Desktops umschalten kann schön animiert werden aber die eigentlichen Anwendungen sind manchmal schon noch sehr laggy find ich.

[Anonymer Nutzer]

Ja eben, das ist ja der Punkt worauf ich in dem Thread "Frage an IT-Profis" hinaus wollte.
Die eigendlichen Anwendungen haben vom Compositor doch gar keinen Schimmer und profitieren davon auch nicht. Die zeichnen immernoch im Schneckentempo ihre unbeschleunigten Sachen auf den Schirm, woran der compositor auch nichts ändern kann.
Ich stell mir halt vor, dass er lediglich bereits gezeichnetes schneller wiedergeben kann und eben mit mehr oder weniger sinnlosen Effekten nachbearbeitet. Aber genaues weiß ich eben leider auch nicht. Werden die Fenster als Texturen gespeichert? hmmm ....

[smurfy]

Das verändern der Größe ist bei mir (Lenovo W530) mit der Nvidia-Karte (Quadro K2100, 2GB, Treiber 304.37) auch etwas laggy. Ich empfinde es zwar als ausreichend schnell, also als nicht störend, aber könnte auch ruhig flüssiger sein.

Richtig schnell geht es mit der eingebauten Intel-Karte (HD4000). Wenn ich diese nutze, dann empfinde ich die ganze Oberfläche als verdammt schnell. Selbst wenn im Hintergrund die QuadCore-CPU voll ausgelastet ist (Gentoo), brachte das bei mir dennoch einen kleinen WOW-Effekt. Zu keiner Zeit war die Oberfläche langsam, egal ob ich unter Belastung nun die Yakuake-Konsole Ein- und Ausfahre, oder ob ich die Größe von Fenstern verändere. So super-flüssig hatte ich das noch nie.

[Nasenbaer]

So schlecht die Intel-Treiber unter Windows (insb. mit Spielen) auch sein mögen, ihr Linux-Treiber-Team scheint wirklich nur aus Profis zu bestehen (so liest es sich regelmäßig auf phoronix.com).

Ich mein es gibt ja Bemühungen auch die Darstellung innerhalb der Anwendung zu beschleunigen. Cairo ist z.B. ne Lib zum Zeichnen von Vektorgraphik. Die Lib hat unter anderem ein OpenGL-Backend. Laut Wikipedia (DE) wird Cairo seit GTK 2.8 für das Zeichnen der meisten Widgets verwendet und Firefox (ab 3.0) nutzt Cairo zum Zeichnen der gesamten GUI und Webseiten.
Die Frage ist ob automatisch das OpenGL-Backend zum Einsatz kommt und ob dieses Dinge auch schneller macht, als die Toolkits früher. OpenGL muss ja nicht gleich heißen, dass alles super schnell geht, kommt ja auch auf die Treiber und die Implementierung innerhalb von Cairo an.

[Anonymer Nutzer]

Nein, cairo-gl ist in keiner Distribution die ich kenne standard. Das "alte" cairo nutzt kein opengl. Mit wayland allerdings wird auch cairo-gl einzug halten und ist eine Abhängigkeit von zB weston. Dann wird auch jede durchscnittsanwendung profitieren.
Ich bewzweifle ob man cairo einfach durch cairo-gl ersetzen kann, da die API bestimmt anders ist.



1 mal bearbeitet, zuletzt am 28.08.12 10:57 durch providus.

[Hello_World]

providus schrieb:
--------------------------------------------------------------------------------
> Ich bewzweifle ob man cairo einfach durch cairo-gl ersetzen kann, da die
> API bestimmt anders ist.
Nein, das API ist das gleiche, egal ob man mittels OpenGL oder z. B. in ein PDF rendert. Unter anderem das ist gerade der Witz an Cairo.

[Nasenbaer]

So hab ich das auch verstanden. Deswegen ist die Ausgabe ja in Backends untergebracht und der Lib-Benutzer greift ja aufs Frontend (also die Cairo-API) zu und weiß nicht, wie das Zeichnen umgesetzt wird.
Habe aber selber nie Cairo genutzt, sondern, dass nur so gelesen.