Parallel zu dem Furore machenden XGL haben Red-Hat-Entwickler in aller Stille an der Alternativtechnologie AIGLX gearbeitet. Auch sie verspricht Hardware-beschleunigte Effekte auf dem Desktop, gliedert sich aber besser in die bestehende X.org-Infrastruktur ein.

Aktuelle Desktop-Technologien sind veraltet. Das zeigt sich vor allem in drei Problembereichen. Erstens sind die gegenwärtigen grafischen Oberflächen auf 2D optimiert, moderne Grafikkarten aber auf 3D. Die dritte Dimension in den Desktop zu integrieren ist schon lange ein Ziel, das bisher aber vor allem an technischen Hürden scheiterte.

Das zweite Problem besteht darin, dass grafische Elemente direkt in den Front-Buffer gerendert werden. Rendering-Artefakte sind daher unmittelbar sichtbar, während die Grafikkarte die Elemente zeichnet. Meist geht das zwar so schnell, dass nur ein paar Ungenauigkeiten zu erkennen sind. Manchmal kann der Benutzer aber auch in aller Ruhe dem Aufbau ganzer GUI-Elemente zusehen. Bisher gingen GUI-Toolkits damit so um, dass sie in Pixmaps im Host-Speicher zeichneten und das fertige Bild in den sichtbaren Bereich kopierten.

Ein dritter Makel ist die recht statische Natur von Fenstersystemen: Entweder wechseln Fenster ihren Zustand ganz ohne Übergang oder mit sehr einfachen Animationen. Wenn zum Beispiel Fenster minimiert oder maximiert werden, erscheinen sie entweder ganz plötzlich aus dem Nichts oder das Fenstersystem zeichnet andeutungsweise die sich vergrößernden Umrisse.

Das alte Rad benutzen

Der OpenGL-Composite-Desktop, den Red Hat mit AIGLX anstrebt, soll alle beschriebenen Schwierigkeiten überwinden. Er beruht auf einigen Schlüsseltechnologien, die in den letzten Jahren entwickelt wurden: Direct-Rendering-Infrastruktur (DRI), X-Erweiterung Composite, Luminocity.

Während der 90er Jahre war Mesa [1] die einzige freie Implementation des OpenGL-Standards. Dabei handelt es sich um eine Client-seitige reine Softwarelösung. Erst 1998 begann die Firma Precision Insight damit, die Direct-Rendering-Infrastruktur [2] zu implementieren. Das machte Hardware-beschleunigte 3D-Grafik unter Linux möglich, allerdings nur für Direct-Rendering-Anwendungen. Indirektes Rendering funktionierte nur mit Mesa.

Die DRI lässt Anwendungen über die OpenGL-Schnittstelle auf 3D-Hardware zugreifen. Diese Programme wissen nichts über die darunter liegende Hardware, weil die DRI einen kartenspezifischen Treiber lädt, der alle beschleunigten OpenGL-Funktionen verarbeitet. Die Treiber wiederum besitzen ein festgelegtes Set an Einstiegspunkten, die sich um die Initialisierung kümmern und direkt in die Libgl-Bibliothek einhängen.

Umleitung mit Composite

Ein weiterer Meilenstein auf dem Weg zum modernen Desktop ist die Entwicklung der Composite-X-Extension [3], die es erlaubt, 2D-Pixeldaten in den Hauptspeicher oder nicht sichtbare Pixmaps umzuleiten. Anwendungen können diese Pixeldaten in den Bildschirmspeicher kopieren, um jene Bereiche zu aktualisieren, die der Benutzer sieht. Damit wird zum Beispiel Double-Buffering möglich, eine Technik, die das Flackern bei Animationen eliminiert.

Auch mit der alten Double Buffer Extension (DBE) des X-Servers war einfaches Double Buffering zwar bereits möglich. Die Composite-Erweiterung erlaubt es aber darüber hinaus einer zentralen Anwendung, genau zu steuern, wann die Fensterdarstellung umzuleiten und die Pixeldaten in den Bildschirmspeicher zu kopieren sind.

Somit muss nicht länger jede einzelne Anwendung über den Prozess Bescheid wissen wie bei DBE. Zudem erlaubt es Composite, einfacher Bildschirm-Lupen für Sehbehinderte zu implementieren, und legt die Grundlage für durchscheinende Fenster und Schatten.

Gegen Ende 2004 begann Red Hat im Luminocity-Projekt [4] damit, umgeleitete Fenster mit OpenGL zu rendern. Die vorher entwickelten Composite-Manager wie Xcompmgr kopierten die Fensterdaten noch über die Render-Extension auf den Bildschirm.

Luminocity

Die zentrale Idee hinter Luminocity ist, aus den Pixeldaten der umgelenkten Fenster OpenGL-Texturen zu erzeugen und diese auf texturierte Rechtecke im sichtbaren Puffer zu zeichnen. Weil zum damaligen Zeitpunkt Hardware-beschleunigtes OpenGL nur über DRI möglich war, benutzt Luminocity ebenfalls Direct Rendering. Das Problem dabei ist, dass die Pixeldaten erst vom Client zum X-Server kopiert werden müssen, bevor sie als Textur verfügbar sind. Dieser zusätzliche Kopierschritt beeinträchtigt allerdings die Geschwindigkeit.

Als weitere Neuerung vereinigt Luminocity auch zum ersten Mal die Funktionen von Composite- und Window-Manager – frühere Composite-Manager benötigten noch einen zusätzlichen Window-Manager. Durch diese Kombination der Funktionalitäten kann Luminocity nicht nur Fensterdaten in den Bildschirmspeicher kopieren und statische Effekte wie Schatten erzeugen, sondern auch Zustandsübergänge animieren.

Zum Beispiel bringt Luminocity den Schwabbelnde-Fenster-Effekte (Wobbly Windows) mit, bei dem ein System mechanischer Federn als Modell für die Fenster dient: Zieht der Benutzer an einer Ecke eines Fensters, verformt es sich, als ob jemand an einer Feder zöge (Abbildung 1).

Abbildung 1: AIGLX macht’s möglich: schwabbelnde Fenster auf dem Desktop. Ein System von mechanischen Federn modelliert das Verhalten des Fensters, wenn es bewegt wird.

AIGLX

Ein Hauptgrund für die Performance-Probleme von Luminocity ist die Anzahl der Kopiervorgänge, die erforderlich sind, um aus umgeleiteten Fensterdaten für die 3D-Hardware geeignete Texturen zu machen. Das Ziel ist es daher, in Zukunft ganz auf das Kopieren von Pixeldaten zu verzichten, also ein umgelenktes Fenster im richtigen Format im nicht sichtbaren Bildschirmbereich so zu zeichnen, dass die Grafikkarte die Daten direkt als Texturen verwenden kann (Abbildung 2).

Abbildung 2: Alt und neu: Die Darstellung der Fensterinhalte nimmt beim Composite-Desktop einen Umweg, der die Berechnung weiterer Effekte ermöglicht, zum Beispiel die Transparenz überlappender Fenster.

Zu diesem Zweck hat Red Hat zwei Technologien implementiert, die eine entsprechende Infrastruktur bilden sollen: Accelerated Indirect GLX (AIGLX) und die OpenGL-Extension »EXT_texture_from_pixmap« (TFP). Darauf beruhend entstand eine Compositing-Bibliothek, die auf Szenengraphen basiert. Der Window-Manager Metacity wiederum greift auf die Bibliothek zurück, um die OpenGL-Animationseffekte zu realisieren.

Indirektes Rendern beschleunigt

Wie erwähnt war indirektes Rendering zu Beginn im DRI-Projekt überhaupt nicht beschleunigt. Pläne dafür, beschleunigtes indirektes Rendering mit dem gleichen kartenspezischen Treibercode zu implementieren, den auch die Client-seitige Libgl verwendet, hatte es zwar bereits gegeben. Das war keine einfache Aufgabe und zum Wunsch nach einem OpenGL-basierten Composite-Desktop fehlte die letzte Motivation.

Mesas Softwaretreiber im ursprünglichen DRI basierte auf der Client-Implementation von Mesa, die OpenGL-Requests in X-Zeichenbefehle umsetzt. Red Hat änderte diesen Code so, dass er statt der Aufrufe der LibX11-Funktionen die entsprechenden internen X-Server-Funktionen aufruft, und gab dieser Implementation den Namen GLcore. Die Schnittstellen, um GLcore zu initialisieren und aufzurufen, waren die Datenstrukturen »__GLinterface« und »__GLdrawablePrivate«, die Teil der OpenGL-Sample-Implementation (SI, [5]) sind.

Neue Architektur

Das DRI-Projekt benutzt aber Mesa anstelle der Sample Implementation, sodass die kartenspezifischen Treiber dem Mesa-Interface entsprechen, das sich stark von GLcore unterscheidet. Die Möglichkeit, DRI- und Mesa-Treiber der Grafikkarten für AIGLX nutzen zu können, macht es also erforderlich, diese beiden Schnittstellen einander anzupassen. Dieser Umstand erschwerte die Implementation von AIGLX und kostete viel Entwicklungszeit.

Red Hat entwickelte eine neue Abstraktionsschicht [6], die sich stark an das DRI-Interface anlehnt, um die Lücken zwischen Server-seitigem GLX-Erweiterungscode und kartenspezifischen Treibern zu stopfen. Das neue Interface stellt drei Objekte zur Verfügung: »__GLXscreen«, »__GLXcontext« und »__GLXdrawable«. Die Methoden, um DRI-spezifische Objekte zu erzeugen und Funktionen des kartenspezifischen Treibers aufzurufen, sind völlig in dieser Abstraktionsschicht namens DRI-Provider gekapselt.

Weil es nicht für alle Karten 3D-Treiber gibt und einige Server mit GLX-Support keine Hardwaretreiber nutzen können (wie Xnest), muss das GLcore-Interface weiter erhalten bleiben. Red Hat schrieb deshalb die oberste Schicht von GLcore so um, dass es die neue Schnittstelle nutzt. Damit lässt es sich bei Bedarf anstelle der kartenspezifischen Treiber einsetzen (Glcore-Provider).

Um für jeden Bildschirm das GL-Modul zu initialisieren, wird ein Stack von GL-Providern aufgerufen. Der erste, der einen nicht mit Null belegten »__GLXscreen« zurückgibt, ist dann für den Bildschirm zuständig. Die künftigen GL-Module können auf diese Weise eigene »__GLXprovider« implementieren und sich in den Provider-Stack einhängen.

Texturen aus Pixmaps

Das beschleunigte indirekte OpenGL-AIGLX erlaubt es, innerhalb des X-Server-Prozesses zu rendern. Trotzdem ist es weiterhin erforderlich, die umgeleiteten Fenster-Pixeldaten mit der Composite-Extension als Textur zu verwenden. Das übernimmt nun die GLX-Extension Texture-From-Pixmap.

Ein einfacher Ansatz könnte die Pixeldaten zum Beispiel mit »XGetImage« über das X-Protokoll kopieren. Oder der Anwender könnte sie über Shared Memory in den Adressraum des X-Clients einblenden, woraufhin der direkt gerenderte Composite-Manager sie als Quelle für einen Aufruf von »glTexImage2D« oder »glDrawPixels« heranzieht. In der Praxis funktioniert das aber leider nicht, weil der Overhead beim Kopieren der Pixeldaten von und zu dem Videospeicher recht groß ist.

Der bessere Weg ist, die Pixmap-Daten im Adressraum des X-Servers zu belassen, wo sie auch gerendert werden, und sie direkt als Quelle für eine Textur-Operation heranzuziehen. Die neue Extension »GLX_EXT_texture_from_pixmap« macht genau dies. Die optimale Lösung wäre, die Fensterinhalte von der Grafikkarte in einen nicht sichtbaren Speicherbereich rendern zu lassen, wo sie ohne weiteres Kopieren als Texturen zur Verfügung stehen. Um dies Verfahren zu implementieren, ist zusätzliche Arbeit an der Infrastruktur nötig, zum Beispiel beim Speichermanagement, genauso wie die Erweiterung der kartenspezifischen Treiber. An beiden Bereichen arbeiten Red-Hat-Entwickler zurzeit.

Die aktuelle Zwischenlösung für das Textur-aus-Pixeldaten-Problem (Texture From Pixel, TFP) leitet die Fensterdaten als Pixmaps in den Hauptspeicher um. Sie ruft dann die Textur-Operationen der Mesa/DRI-Treiber durch die neue AIGLX-Abstraktionsschicht auf. Das Rendern in Hauptspeicher-Pixmaps erspart das Lesen aus dem Framebuffer, das zum Teil sehr langsam ist, vor allem auf AGP-Hardware. Diese Zwischenlösung ist komplett implementiert und zeigt für eine Technologie-Preview eine recht ordentliche Leistung.

Window-Manager mit Compositing

Luminocity bietet als rudimentärer Window- und Composite-Manager die Möglichkeit, schnell Prototypen neuer Technologien zu entwickeln und die Brauchbarkeit von OpenGL als Desktop-Technologie zu erforschen. Es wäre natürlich denkbar gewesen, das Programm zu einem vollständigen Window-Manager auszubauen. Das hätte aber bedeutet, die vielen Jahre an Entwicklungszeit, die in Metacity stecken, noch einmal zu investieren. Stattdessen entschlossen sich die Entwickler dazu, die mit Luminocity erworbenen Kenntnisse in Metacity einzubauen.

Der Ansatz ist, eine auf OpenGL basierende Szene-Graph-Bibliothek zu implementieren: die Libcm. Sie kapselt die Methoden, mit denen der Window-Manager den Desktop zeichnet. Metacity kann dann nach Bedarf einzelne Effekte in den Szene-Graphen einhängen oder aus ihm entfernen. Weil dabei der ganze Umfang von OpenGL zur Verfügung steht, begrenzen nur die Fähigkeiten der Hardware den Umfang der Animationen. Effekte, die es schon gibt oder die gerade implementiert werden, sind die Minimierung von Fenstern, das Ein- und Ausblenden von Menüs, Schlagschatten (Drop Shadows), Transparenz und die Umschaltung virtueller Desktops.

Obwohl AIGLX und TFP für den GL-basierten Composite-Desktop zusammenarbeiten, sind sie eigentlich voneinander unabhängig. Deshalb können Anwendungsentwickler beide Technologien auch separat nutzen, wenn es ihr Programm erfordert. Der Window- und Composite-Manager Compiz [7] des XGL-Projekts (siehe den entsprechenden Artikel in diesem Schwerpunkt) verfolgt beispielsweise einen etwas anderen Ansatz. Mit Hilfe der vorgestellten Technologien arbeitet er aber auch mit dem Standard-X.org-Server zusammen [8].

Es gibt viel zu tun

Die aktuelle Technology Preview von AIGLX rendert Fensterinhalte in Pixmaps im Arbeitsspeicher des X-Servers. Die Pixmaps stehen den GL-Anwendungen dann über die Texture-From-Pixmap-Erweiterung als Texturquelle zur Verfügung. Damit fallen außer dem letzten alle Kopiervorgang weg, was das Rendering deutlich beschleunigt. Einige Demo-Videos, eine Anleitung zur Installation auf Fedora Core 5 und andere Informationen finden sich auf [9].

Bis zum fertigen Composite-Desktop bleibt noch einiges zu tun. Red Hat und andere Entwickler der Open-Source-Community sind dabei, noch fehlende Technologien zu implementieren: Speichermanagement, Umleitung verbreiteter X-Extensions wie Xv, GL und DRI, Framebuffer-Objekte, FBconfigs sowie vollständige Unterstützung von GLX 1.3. Sind diese Technologien verfügbar, fließen sie schrittweise in den GL-basierten Composite-Desktop ein. (ofr)