How Xgl, X.Org, Mesa and Compiz work

cube-with-matrixI searched around a bit today to find some more information about how AIGLX works, how Xgl works, how everything is related to Xegl, and so on.

Though I still haven’t answered all my questions (e.g. what Xegl will have/Xgl has what AIGLX is not providing already) I found a very interesting page which gives understandable explanations: Communication between Xorg, Xgl, and an OpenGL client, through libGL and the GLX Protocol. It is focussed on Xgl but you will find explanatory themes for AIGLX as well – and these show by the way very good why Xgl is in a way a hack while AIGLX is very integrated into the current X.Org structure.

And I really like the way how this page explains the communications process between for example Xgl and Mesa:

Mesa libGL: “Hello Xgl GLX Extension. I need an OpenGL Context for my client (that’s Compiz).”
Xgl GLX Extension: “Sure, I’m giving an Indirect OpenGL Context to you. Now you can use OpenGL functions through the GLX Protocol.”

That can be understand by everyone.

2 thoughts on “How Xgl, X.Org, Mesa and Compiz work”

  1. As I understand it, in Xgl (or Xegl) _everthing_ on the desktop is accelerated through OpenGL, even toolkits which uses X11/XRender (well, something only if your card supports glx_ext_texture_from_pixmap extension). As I understand it, in AIGLX (or if you use new NVidia beta drivers) only Compiz is accelerated through OpenGL, but X11/XRender is still X11/XRender and it doesn’t go through OpenGL. But there is one solution which brings full OpenGL acceleration to standard X.Org server with AIGLX: Glucose (new OpenGL based acceleration architecture for X.Org by Zack Rusin, if I remember you have also written about it).

    Or you must use toolkits which supports OpenGL as rendering backend – for example Qt 4 and his Arthur paint system.

Comments are closed.