Composition-Manager
Ein Composition-Manager ist eine Software, die es ermöglicht, Compositing-Techniken bei Bildschirmausgaben von Computern zu benutzen. Composition-Manager spielen eine besondere Rolle bei der Nutzung hardwarebeschleunigter Effekte auf normalen Desktops. So sind die dort genutzten Eye-Candy-Effekte wie Transparenz, 3D-Darstellung, stufenloses Zoomen und Live-Vorschauen von Videos oder animierten Sequenzen erst mit Hilfe der Composition-Manager möglich.
Der X.Org-Server verwendet, ebenso wie die X-Erweiterungen oder -Abwandlungen Xgl und AIGLX Composition-Manager, um mit Hilfe von OpenGL verschiedene Effekte zu beschleunigen. Verwendete Composition-Manager sind dabei kompmgr, xcompmgr, Compiz, KWin und Metacity (mit Erweiterungen). Dabei sind Compiz, KWin und Metacity auch Fenstermanager. Man bezeichnet solch eine Kombination aus Composition-Manager und Fenstermanager auch als Compositing Window Manager.
Zweck von Composition-Managern
Beim klassischen X ohne Composition-Manager werden die Fenster einfach nur mit 2D-Grafikfunktionen (in Soft- oder Hardware, d. h. per CPU oder 2D-Grafikprozessor) auf den Desktophintergrund gezeichnet. Dies bewirkte, dass Fenster, wenn sie ganz oder teilweise von anderen Fenstern verdeckt waren, aber sichtbar werden (z. B. weil die oberen Fenster verschoben werden), neu gezeichnet werden müssen (bezeichnet man als damage). Composition-Manager erfüllen demgegenüber die Aufgabe, die Fenster von laufenden Applikationen grafisch zu kombinieren, bevor sie dargestellt werden. Dies führt in der Regel die 3D-Hardware (die Grafikkarte oder die Grafik-Einheit im Chipsatz) durch, die Fenster werden also in Texturen umgewandelt und von der Grafik-Einheit zum Gesamt-Bildschirminhalt kombiniert. Hierdurch wird das manuelle Behandeln der ungültigen Bereiche unnötig, und diese Technik ermöglicht diverse Effekte beim Kombinieren der Fenster, wie z. B. Transparenz oder Animation.
Beispiele
Siehe auch
Auf dieser Seite verwendete Medien
(c) Shmuel Csaba Otto Traian, CC BY-SA 3.0
Schema der Schichten der Grafische Benutzeroberfläche
(c) Shmuel Csaba Otto Traian, CC BY-SA 3.0
en:Wayland (display server protocol)
① The en:evdev module of the en:Linux kernel gets an event and sends it to the en:Wayland compositor. This is similar to the X case, which is great, since we get to reuse all the input drivers already in the kernel.
② The Wayland compositor looks through its scenegraph to determine which window should receive the event. The scenegraph corresponds to what's on screen and the Wayland compositor understands the transformations that it may have applied to the elements in the scenegraph. Thus, the Wayland compositor can pick the right window and transform the screen coordinates to window local coordinates, by applying the inverse transformations. The types of transformation that can be applied to a window is only restricted to what the compositor can do, as long as it can compute the inverse transformation for the input events.
③ As in the X case, when the client receives the event, it updates the UI in response. But in the Wayland case, the rendering happens in the client, and the client just sends a request to the compositor to indicate the region that was updated.
④ The en:Wayland compositor collects damage requests from its clients and then re-composites the screen. The compositor can then directly issue an en:ioctl to schedule a pageflip with KMS