OpenGL & X
last updated: 30. January 2007 There is still quite a bit confusion about the new and shiny OpenGL acceleration on the Linux desktop.Therefore I will try to explain how the buzzwords XGL, AIGLX, Compiz et al. are connected.
So lets begin top down:
Compositing Manager
The highest level in the rendering stack is the compositing manager - it is a relatively new component, which manages the window compositing usually keeping the windows in some kind of off-screen memory.
Before the compositing managers were introduced, only the visible window areas were kept in memory and underlying windows had to be redrawn if an upper window was moved. This was quite slow and prevented effects like transparency, since no information was saved about the area behind the window.
Compiz is probably the most prominent compositing manager nowadays - it uses OpenGL to store the windows in textures, which in the first place allows all the cool effects like transformation(wobbly plugin), fast resizing(scale plugin) and multiple rendering targets(switcher plugin).
You can also place the textures on all kind of geometric shapes - like the cube which is used for the workspace switcher.
But you also need a window manager to move the windows around and actually take advantage out of the compositing manager. This is when gnome-window-decorator comes in play.
Because the Compiz development first concentrated on a good application design, while there was a high interest in what could be done with compiz, a fork called beryl was created which concentrated on new effects instead.
Today the better application design of compiz pays off, and the project advances faster, while beryl has problems with reaching a stable codebase.
The Metacity compositor previously mentioned here can now be considered dead. Although there is some work being done to get basic compositing work, the general agreement is to concentrate on compiz and use metacity only as a fallback when no compositing capable hardware is present.
Accelerated X-Server
The compositing managers need an X-Server which is able to provide an indirect OpenGL context. Currently XGL and AIGLX are able to do this.
This means that although Compiz is being mostly connected with XGL it is also possible to run it on AIGLX - or the other way round it would require only few work to get Metacity running on XGL.
AIGLX and XGL are quite similar; they both provide the same functionality and the both rely on the same GLX extensions - the difference is their concept.
XGL is designed as an stand alone X-Server making all its drawing using OpenGL and is thus the long term solution. But right now the only available XGL implementation Xglx runs as a fullscreen application on the Xorg server because it relies on its input device handling, since it does not implement its own.
This will change once it will be replaced by Xegl but this will take a long time, since Xegl will not use OpenGL anymore but like its name already suggests EGL which is a wohle new API that also needs to be properly supported by the graphic drivers.
And if you consider how long it takes the propietary drivers to support EXT_texture_from_pixmap, which is just one extension, you can image which way we still have to go here.
AIGLX on the other hand is designed as an extension to the current Xorg server architecture and is available right now in the new Xorg 7.1 release.
Nevertheless it still needs EXT_texture_from_pixmap which is still not available and therefore Xglx, which uses the CPU to emulate this extension is ironically the only available solution.
But there is actually no choice between AIGLX and XGL (in its current form); AIGLX is the way to go for the next time but it will be replaced by XGL in long term, when Xegl will become available.
So there is also no competition between XGL/ AIGLX; both projects actually are sharing code and working together to be as compatible to each other as possible, since this eases the development of compositing managers and guarantees an easy interchangeability.
technical details
for more technical details I recommend Emanuele Tamponi's article