PDF-Version - freiesMagazin

ist, ob der „Schließen”-Knopf gedrückt wurde und
um wie viele Pixel die Eingabe verschoben werden
muss, um ein Fenster über den Würfel zu
bewegen. Eine zentrale Komponente wie den X-
Server gibt es nicht mehr. Und dies ist genau die
Architektur von Wayland.
Die Mär der Netzwerktransparenz
Verfolgt man die Diskussionen zu Wayland in diversen
linuxnahen Foren, so scheint die Netzwerktransparenz
das Killerfeature zu sein, ohne
das niemand einen Linux-Desktop einsetzen
würde [18]. Jedoch ist fraglich, ob die X-
Netzwerktransparenz heute überhaupt noch sinnvoll
ist. Wie oben bereits angesprochen, ist die
Netzwerktransparenz eher ein Nebenprodukt der
Anforderungen der 80er, die eine Client/Server-
Architektur benötigten.
Heute zeichnen Anwendungen jedoch mittels
OpenGL und nicht mehr über X11. Dies führt
zu einigen unangenehmen Auswirkungen für die
Netzwerktransparenz. Das Protokoll ist optimiert
für das Zeichnen von Primitiven mittels X11. Nun
zeichnen die Anwendungen entweder auf Software
emuliert (z. B. Qt Raster Engine) oder hardwarebeschleunigt
mittels OpenGL. In vielen Fällen
wird einfach in eine Pixmap gezeichnet und
mittels Blitting auf den Bildschirm bzw. die offscreen
Pixmap transferiert. Widget Styles wie
z. B. Oxygen aus dem Hause KDE setzen massiv
auf Animationen. Diese benötigen sehr viele Pixmaps,
die jedes Mal an den X-Server übertragen
werden. Selbst in einem lokalen Netzwerk kann
hierbei das Protokoll schnell an die Grenze kom-
men. Zum Übertragen von „Video” ist X11 aber
nun wirklich nicht gedacht, denn es war optimiert
für die primitiven Anforderungen des letzten Jahrhunderts.
Ein anderes Problem für moderne Anwendungen
ist die komplett fehlende Netzwerktransparenz
von D-Bus. Kaum eine Anwendung kommt heute
noch ohne D-Bus aus. Eine Benachrichtigung
würde also an den falschen Rechner gesendet,
Application Indicators werden in den falschen
Systemabschnitt integriert, das Menü wird einfach
nicht angezeigt und viele weitere Probleme
werden in Zukunft auftreten. Dass die Netzwerktransparenz
mit Wayland nicht mehr funktionieren
wird, liegt nicht primär an Wayland, sondern
daran, dass sie nicht mehr zeitgemäß ist.
Als Ersatz für die Netzwerktransparenz wurde
vorgeschlagen, diese direkt in die Toolkits (also
GTK+ und Qt) zu integrieren – und dies
wäre auch sinnvoll. Als Beispiel seien hier einmal
Icons genannt. Für Icons gibt es eine
freedesktop.org-Spezifikation [19]. Icons können
über die verschiedenen Arbeitsflächen hinweg
einheitlich angesprochen und ausgewählt werden.
Mit X wird das Icon vom entfernten Rechner
geladen und als Bild übertragen. Es weiß nichts
über das verwendete Icon-Theme auf dem Zielrechner.
Verlagert man die Netzwerktransparenz
in das Toolkit, könnte die entfernte Anwendung
einfach das Icon vom lokalen Rechner laden, sofern
es dort vorhanden ist. Die komplette Übertragung
des Icons ist somit wegoptimiert und die
Anwendung fühlt sich nativer und lokaler an.
DESKTOP
Wayland kann auch X-Clients anzeigen und somit
ist es auch in Zukunft möglich, noch die X11-
Netzwerktransparenz zu nutzen. Noch auf Jahre
werden Anwendungen X unterstützen. Das Argument
der fehlenden Netzwerktransparenz ist für
Wayland einfach nicht haltbar. Nutzer, die von
Wayland profitieren, wissen nicht einmal, was die
Netzwerktransparenz ist oder wofür sie sie einsetzen
sollten. Die Zukunft von Wayland liegt mit
Sicherheit auch bei Smartphones. Daher ist es
nicht überraschend, dass Wayland OpenGL ES
verwendet und von Intel gesponsort wird.
Wie geht es weiter?
Bis Wayland für die Nutzer einsetzbar wird, wird
noch einige Zeit vergehen: Toolkits müssen portiert
werden, um von Wayland zu profitieren,
Desktopumgebungen müssen sich von X lösen
und Fenstermanager zu großen Teilen neu geschrieben
werden. Die Arbeit dazu hat bisher
höchstens im konzeptionellen Bereich begonnen.
KDE Plasma dürfte von der existierenden Portierung
auf Microsoft Windows profitieren, da
es zeigt, dass man Plasma ohne X11 verwenden
kann. Etwas komplizierter dürfte es für X-
Fenstermanager werden. Diese wurden speziell
für X entwickelt und gehen so ziemlich überall
davon aus, dass sie auf X laufen. Fenstermanager,
die bereits einen Compositor integrieren, haben
hier zumindest einen Vorteil. Jedoch verwendet
kaum ein Fenstermanager OpenGL ES. Der
KDE Fenstermanager KWin befindet sich aktuell
in Portierung und wird demnächst in die Hauptentwicklungslinie
Einzug erhalten [20].
© freiesMagazin CC-BY-SA 3.0 Ausgabe 03/2011 6