Mit Hilfe von OpenGL lassen sich Grafikoperationen moderner Desktops wesentlich beschleunigen. Der XGL-X-Server realisiert im Zusammenspiel mit dem Composite-Manager Compiz beeindruckende Effekte.

Groß war einst die Begeisterung der Mac-Fans, als Apple die Grafikschnittstelle Quartz Extreme vorstellte [1], die Desktop-Effekte mit 3D-Hardware beschleunigt. Demnächst wird Microsofts Windows Vista mit Aero zum Mac aufschließen. In der Unix-Welt hat Novell/Suse mit XGL [2] eine vergleichbare Technologie implementiert, die ähnliche Effekte und Bedienkonzepte ermöglicht.

Fortschritt

Nach längerem Stillstand bei der Entwicklung des X-Servers haben die Programmierer in den letzten Jahren neue Funktionen eingebaut, welche die Basis für die neue XGL-Technologie legten. Moderne GUI-Bibliotheken wie Qt und GTK verwenden bereits etliche dieser neuen Funktionen, ohne dass der Benutzer von ihrer Existenz weiß. Die beiden wichtigsten Protokollerweiterungen Render und Composite spielen auch für XGL eine wichtige Rolle.

Die Render-Erweiterung führt neue Basisprimitive für die Darstellung von Bildern und Polygonen ein sowie ein neues Glyphensystem für verbesserte Schriftdarstellung. Damit wird insbesondere dem Umstand Rechnung getragen, dass die alten Grafikbefehle – so genannte Core Requests – nicht mehr den Anforderungen aktueller Toolkits wie Qt und GTK entsprechen.

Alle Primitive lassen sich nun über die Porter-Duff-Operatoren [3] mit den bereits im Framebuffer befindlichen Daten verknüpfen, was unter anderem die Darstellung semitransparenter Flächen (Alpha Blending) und Schriften mit Antialiasing (Pixel Coverage) erlaubt. Gerade von Letzterem machen viele moderne Anwendungen ausgiebig Gebrauch.

Das bisher in X11 verwendete Fenstersystem erlaubt zwar überlappende Fenster, bietet aber keine Möglichkeit, in unsichtbaren Fensterbereichen zu zeichnen und deren Inhalt auf irgendeine Weise darzustellen. Dies ist nur möglich, wenn alle Fenster erst in einen nicht sichtbaren Bereich des Framebuffers gezeichnet werden, um sie danach im sichtbaren Framebuffer zusammenzufügen (Compositing). Genau dies macht die Composite-Erweiterung des X-Servers.

Das Zusammensetzen aller Fenster zu einem stimmigen Ganzen übernimmt ein externer Prozess, der Composite-Manager heißt, analog zum altbekannten Window-Manager. Er kann zum Beispiel mit Hilfe der Render-Erweiterung mehrere Fenster semitransparent übereinander zeichnen. Da Composite- und Window-Management eng verzahnt sein müssen, werden in Zukunft immer mehr so genannte Composite-Window-Manager auftauchen, die beide Prozesse miteinander verschmelzen.

Schneller zeichnen

Ein weiterer wichtiger Bestandteil des X-Servers, der dringend einer Erneuerung bedarf, ist die Beschleunigungsarchitektur, die für die effiziente Umsetzung der Grafikbefehle auf die Hardware zuständig ist. Die bisher verwendete Architektur XAA ist auf Core Requests zugeschnitten und nur schwer erweiterbar. Daher ist sie am Ende ihrer langen Laufbahn angekommen und muss vollständig ersetzt werden. Die den größten Erfolg versprechenden Alternativen heißen EXA und OpenGL.

Während EXA relativ übersichtlich und leicht zu implementieren ist (siehe den Artikel zu X.org in diesem Heft), besitzt OpenGL den Vorteil, eine weit verbreitete Programmierschnittstelle zu sein, für die es bereits funktionierende Treiber gibt. Der X-Server braucht sich also nicht selbst um die Ansteuerung der Hardware zu kümmern. Außerdem muss mit einem OpenGL-basierten Server in der fernen Zukunft nur noch eine Schnittstelle zur Grafikhardware gepflegt werden und nicht zwei getrennte Systeme für XAA/EXA und OpenGL.

X-Server mit OpenGL

XGL ist ein vor allem von David Revemann (Novell) geschriebener X-Server, der die Grafikausgabe über OpenGL realisiert. Wenn ein Programm XGL anweist eine Linie zu zeichnen, übergibt XGL die Endpunkte (Vertices) an das OpenGL-Subsystem, das die entsprechenden Befehle an die Grafikkarte richtet.

Trotz OpenGL bleibt bei XGL das Protokoll gleich, mit dem Applikationen sich an den X-Server wenden, es müssen also keine Programme umgeschrieben werden. Außerdem beschleunigt XGL eben nicht die Ausführung von OpenGL-Programmen, wie oft behauptet wird.

Im Gegenteil: Aus technischen Gründen ist zurzeit überhaupt nur indirektes Rendering möglich. Alle OpenGL-Befehle werden also über das GLX-Protokoll an XGL geschickt und erst dort an die Grafikhardware übergeben. Indirektes Rendering ist bei Programmen mit hoher Polygonzahl (Spiele) oder hohem Texturaufkommen (Video) deutlich langsamer als direktes Rendering.

Derzeit kann XGL (noch) nicht nativ auf die Hardware zugreifen, es muss also auf ein System aufsetzen, das den Framebuffer initialisiert und eine OpenGL-Schnittstelle zur Verfügung stellt. Aktuell ist das der gewohnte X-Server von X.org, das heißt, XGL öffnet – ähnlich wie Xnest – auf dem X.org-Server ein Fenster, das den gesamten Bildschirm bedeckt. Danach können sich X-Applikationen mit XGL verbinden, der Standard-X-Server hat hingegen während der gesamten Sitzung XGL als einzigen Client.

Die vom Server zu bearbeitenden X11-Befehle sind teilweise relativ komplex, deshalb kapselt eine Zwischenschicht die Anweisungen an OpenGL. Diese Bibliothek namens Glitz ist im Wesentlichen das OpenGL-beschleunigte Backend von Cairo, einem System für auflösungsunabhängige Grafikoperationen.

Sobald ein Composite-Manager ins Spiel kommt, verkompliziert sich der übliche Aufbau der Grafikpipeline. Wie Abbildung 1 zeigt, leitet der X-Server zuerst alle Fensterausgaben in nicht sichtbare Bereiche des Framebuffers um. Ein solcher Speicherbereich entsteht mit Hilfe eines »pBuffer« oder Framebuffer-Objekts (FBO). In diesen Speicherbereich werden alle X11-Befehle der Applikation umgeleitet und mit Hilfe von OpenGL gezeichnet. Dies passiert für alle Programme getrennt.

Abbildung 1: Pixelpipeline eines Composite-Managers unter XGL. Der Composite-Manager setzt die im nicht sichtbaren Speicherbereich gerenderten Fensterinhalte zu einem sichtbaren Desktop zusammen.

Danach zeichnet der Composite-Manager Compiz alle Fensterinhalte als Texturen auf OpenGL-Objekte. In der Regel sind dies Rechtecke, es können aber – etwa für Übergangseffekte – auch komplexere und dreidimensionale Objekte sein.

Compositing

XGL ist also nicht selbst für die atemberaubenden Effekte verantwortlich, von denen in letzter Zeit häufig die Rede war. Es erlaubt aber einen Composite-Manager zu schreiben, der selbst OpenGL-Befehle für die Darstellung der Fenster benutzt. Für den normalen X-Server ist das nicht ohne weiteres möglich, da OpenGL nicht mit dem zugrunde liegenden Fenstersystem verknüpft ist, also nicht auf die mit Hilfe von X11-Befehlen gezeichneten Fensterinhalte zugreifen kann.

Da XGL intern OpenGL benutzt, kann es die Fensterinhalte dem externen Composite-Manager mit Hilfe der Erweiterung »GLX_EXT_texture_from_pixmap« zugänglich machen. Diese Extension stellt nicht der OpenGL-Treiber, sondern XGL selber zur Verfügung. Der reguläre X.org-Server bietet diese Erweiterung im CVS seit der Implementation der AIGLX-Erweiterung ebenfalls an (siehe folgenden Artikel), allerdings fehlen noch die Unterstützung für Xvideo und OpenGL auf Anwendungsebene sowie Teile der beschleunigten Grafikbefehle.

Wie erwähnt muss der Composite-Manager den Desktop mit Hilfe von indirektem Rendering zeichnen, es werden also alle OpenGL-Kommandos über das GLX-Protokoll an XGL geschickt und erst dort an die Grafikhardware übergeben. Nur auf diese Weise kann ein anderer Prozess die Texturen einsetzen, die ja im Adressbereich von XGL liegen.

Das gleiche Problem betrifft auch alle OpenGL-Anwendungen, da sie in einen nicht sichtbaren Bereich des Framebuffers zeichnen müssen, der ebenfalls im Adressbereich des X-Servers liegt. Einzelheiten dazu finden sich in [4].

Dritte Dimension

Benutzeroberflächen sind im Allgemeinen für die Bedienung mit der Maus ausgelegt, die ein zweidimensionales Eingabegerät ist. Also ist es nahe liegend, die Oberflächen ebenfalls zweidimensional zu gestalten, wofür sich das X-Protokoll beziehungsweise die Render-Erweiterung hervorragend eignen. Andererseits ist der Mensch darin geübt, dreidimensionale Szenen zu verstehen.

Die Projektion der Benutzeroberflächen auf eine dreidimensionale Desktop-Welt kann also ebenfalls sinnvoll sein, solange die Interaktion mit nicht-zweidimensionalen Darstellungen von Programmen auf ein Minimum beschränkt bleibt. Echte 3D-Interaktion weist noch eine Reihe technischer Probleme auf und ist typischerweise wenig intuitiv.

Die Projektion von zweidimensionalen Pixeldaten auf dreidimensionale Objekte ist die Standardanwendung für OpenGL, also liegt es nahe, auch für den Composite-Manager diese 3D-Schnittstelle zu verwenden. Zusätzlich bekommt der Anwender Effekte wie die Semitransparenz quasi geschenkt, da sie zum Standardrepertoire von OpenGL gehören. Einen solchen Manager hat nur deshalb bisher niemand programmiert, weil erst die Entwicklung von XGL die OpenGL-Schnittstelle für Composite-Manager verfügbar machte.

Desktop in 3D

Während einer Sitzung mit dem Composite-Manager Compiz fällt die Tatsache, dass OpenGL für die Ausgabe verwendet wird, zunächst gar nicht auf. Lediglich Schatten und leicht semitransparente Fensterdekorationen deuten darauf hin. Erst beim Umschalten auf einen anderen virtuellen Desktop macht sich die dreidimensionale Natur des Desktops bemerkbar (Abbildung 2).

Abbildung 2: Compiz schaltet auf einen anderen virtuellen Desktop um.

Compiz benutzt eine sehr flexible, aber noch nicht völlig stabile Plugin-Architektur für alle seine Effekte. Ein externes Programm berechnet die Fensterdekorationen und stellt sie Compiz zur Verfügung. Auf diese Weise lassen sich recht einfach Themes oder unterschiedliche Widget-Sätze einbinden. Derzeit existiert ein Dekorationsprogramm für Gnome, das allerdings auch mit KDE funktioniert.

Effekte durch Plugins

Compiz-Plugins gibt es sowohl für die Basisfunktionalität des Fenstermanagers (»decoration«, »move«, »place«, »resize«) als auch für erweiterte Funktionalität (»cube«, »scale«, »switcher«) und Effekte (»fade«, »minimize«, »rotate«, »wobbly«, »zoom«). Da Plugins mit vergleichbarer Funktion austauschbar sind, kann der Anwender Compiz leicht an die eigenen Wünsche anpassen. Eine genauere Auflistung der Plugins mit einer Beschreibung ihrer Funktion und Bedienung findet sich unter [5] und [6].

OpenGL-basierte Programme sehen sich oft dem Vorwurf ausgesetzt, dass ihre einzige Daseinsberechtigung in der Darstellung faszinierender Effekte besteht, dem auf Englisch so genannten Eye Candy (Bonbons fürs Auge). Tatsächlich erlaubt diese Technik aber auch nützliche Entwicklungen im Usability-Bereich für sensorisch Behinderte (zum Beispiel mit Hilfe des Zoom-Plugin) sowie die Entwicklung von Selektionshilfen wie Exposé (ein Scale-Plugin), die sich in der Mac-Welt bereits als sehr hilfreich erwiesen haben. Auch die verkleinerte Darstellung von Anwendungen während der Applikationswahl (Abbildung 3) ist sehr nützlich, vor allem wenn sie während der Auswahl live die aktuelle Programmausgabe zeigt.

Abbildung 3: Das Switcher-Plugin mit verkleinerten Livebildern der Applikationen.

Obwohl der Composite- und Window-Manager Compiz noch am Anfang seiner Entwicklung steht, ist er bereits recht gut benutzbar. Es fehlen noch einige Features anderer Fenstermanager, manche Ausnahmen für spezielle Programmtypen sind noch nicht vollständig implementiert, zum Beispiel Miniaturfenster für Panels. Bis zur vollständigen Integration in KDE ist deshalb noch etwas Arbeit nötig.

Weniger Wartung

Ist XGL nun die Zukunft des X-Window-Systems? Die Meinung darüber war auf der letzten X.org Developers\’ Conference [7] im Februar in Santa Clara geteilt. Während ein Teil der X-Entwickler den oft noch schlechten Zustand der Open-Source-Treiber sowie die Unverträglichkeit von proprietären Treibern und GPL anführt, empfinden andere OpenGL als die geeignete Grafikschnittstelle und sähen gerne den kompletten Treibercode aus dem X-Server verbannt. Ein X-Server, der auf der Basis von OpenGL arbeitet, kann auch leichter ein zukünftiges Protokoll unterstützen, das sich nicht mehr um die veralteten Grafikprimitive kümmert und so die Client-Server-Kommunikation verbessert.

Was fehlt

Der größte Schwachpunkt von XGL ist zurzeit die fehlende native Hardware-Unterstützung. Bis auf weiteres ist es auf den X.org-Server als Zwischenglied angewiesen. Ein experimenteller Ableger namens XEGL kann zwar bereits direkt mit der Grafikhardware umgehen, allerdings nur auf R100- und R200-Radeon-Karten. Über den genauen Zustand dieses Servers weiß praktisch niemand Bescheid, weil er schon seit langem als Projektleiche im Repository liegt.

Einig scheinen sich alle Beteiligten nur darin zu sein, dass OpenGL-basierten Composite-Window-Managern die Zukunft gehört. Gerade Compiz könnte aufgrund seiner flexiblen Plugin-Architektur zu dem Fenstermanager der Zukunft werden.

Derzeit befinden sich XGL und Compiz in einem zwar relativ stabilen, aber noch frühen Entwicklungsstadium. Für Open Suse gibt es Pakete [5], mit denen man die neue Technologie relativ einfach ausprobieren kann. Auch in aktuellen Snapshots der kommenden Ubuntu-Release Dapper Drake lassen sich XGL und Compiz installieren.

Zum schnellen Ausprobieren bietet sich eine Gentoo-basierte Live-CD an [8]. Mit einigen Treibern läuft das System bereits so stabil, dass es für die tägliche Arbeit geeignet ist. Weil XGL nicht alle OpenGL-Erweiterungen an seine Clients weiterleitet, funktionieren jedoch etliche OpenGL-Anwendungen und Spiele bislang noch nicht fehlerfrei. (ofr)