Composite-Desktop mit AIGLX

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.