How Luminocity Relates to Other Stuff
March 24, 2005
Relation to Metacity
When it has proved itself, Luminocity’s compositing manager will probably be moved into Metacity (along with any effects / extra features we consider good and stable). We originally considered doing the work in Metacity itself, but didn’t want to destabilize it until various approaches were tested. Luminocity is, effectively, a testbed for Metacity. It provides a smaller/simpler codebase to test interesting rendering code with, and means we don’t have to worry about fucking up Metacity in the process. Soeren’s computer is (as of tonight, at least, that’s the first I saw of it) running a version of Metacity that’s apparently using the compositing manager code from Luminocity to render to a GL context.
Relation to xcompmgr
Luminocity has an internal compositing manager that performs the same function as xcompmgr. The compositing manager / window manager integration allows Luminocity to do things that an individual compositing manager or window manager couldn’t. Of course, Luminocity composites using OpenGL, unlike xcompmgr. This apparently can be an upside and a downside, but I don’t know anything about it so I’ll shut my trap.
Relation to Xgl
This is the complicated one :-). I’m loathe to stick my toes in these waters because I’m the wrong person to do it, but I’m also afraid that we’re going to end up with two rendering infrastructures down the road and no clarity for application developers as to which (if either) they can use. I don’t know if that’s where we’re headed, I hope not, but I have this vague (probably, hopefully unfounded) fear… The effect will be slow adoption and general suck. I should premise this by saying that I have no direct knowledge of the Xgl codebase. I have knowledgable sources, and I know what Xgl generally is, but I haven’t personally used Xgl, let alone looked at its codebase (I’ve barely looked at the Luminocity codebase either, for that matter).
Xgl is an X server implementation that, rather than directly accessing chip specific hardware drivers, does its low-level drawing using OpenGL calls. That means Xgl is functionally equivalent to a traditional X server, it just uses a different rendering path. Put another way, Xgl is to X11 as Glitz is to Cairo: it provides the same APIs rendered in a much smarter way.
Luminocity, on the other hand, is a compositing manager / window manager fusion that composites using OpenGL. Compositing and Window managing are all about what you do with client-rendered windows. Luminocity doesn’t know what’s inside windows, and it doesn’t care. Xgl, on the other hand, I would characterize as primarily being about how the contents of windows are drawn (in this case: quickly and with less CPU load, *grin*). Xgl can do some other non-inside-window things like drop shadows, but I’m going to argue later those are mostly expedient demos of cool technology and Xgl is probably not the place we want to be doing those things long term. From the perspective that Luminocity is mostly about rendering windows and Xgl is mostly about rendering window contents, they are theoretically complimentary. At the moment, they can not be used in conjuction with one another (since they both want to directly drive the GL hardware), but they’re goals are at least compatible.
Neither Xgl nor Luminocity are complete on their own. Xgl provides an X server and requires a window manager (and a compositing manager?) (and an X server for doing GL calls into, but see below, that will hopefully cease to be an issue eventually). Luminocity provides a window manager and a compositing manager but requires an X server (currently using Xfake or Xephyr, though supposedly there’s some plan for modifying the core fd.o X server so Luminocity will work using only the host X server?). With some hand waving (in particular there’s no way to hand OpenGL textures residing in the video card between processes), perhaps we could get Xgl to render windows into textures on the video card, and then use Luminocity to figure out what do with those textures. All graphics computations are done by the card, and data flows only once to the card. Perfect! Other than those niggly make-or-break technical details 😉
As far as I know (and I’m pretty sure of this), there is no systematic way (besides GLX inside a running XFree86 / fdo.o X server) to access the “hardware accelerated OpenGL drivers”. That means that Xgl and Luminocity are currently forced to have a traditional host X server, open a fullscreen window on the host server and draw into it using OpenGL. Both Luminocity and Xgl are premised on OpenGL as the standard API through which vendors can provide graphics hardware acceleration (as opposed to, say, RENDER).
Update: Soeren, one of our X hackers, thinks that Xgl actually includes no cross-window stuff but just uses an existing compositing manager (and of course, accelerates its rendering). In that case, the next couple paragraphs are totally unnecessary. Like I said above, I don’t know anything about the Xgl codebase.
In addition to traditional X server features, Xgl performs some cross-window effects (such as drop shadows). This is the main area where Luminocity and Xgl could be seen as overlapping. As a mentioned before, I would argue that the X server (including Xgl) should not be doing these things long term, for a few reasons. I am not sure if David considers this point contentious or not. It could well be that he too considers these effects just a quick way to get some neat effects in play, not the best way long term, I have no idea.
- Drawing drop shadows on windows in the X server is equivalent to drawing titlebars on windows in the X server (instead of the window manager). One (dumb) example is that this will mean they are outside the purvue of themes (short of having an “X server theme”, *wink*). If you believe in the separation of window manager and xserver (fwiw, I think its valid to believe that wm and xserver should be merged), that’s an argument against doing this sort of effect in Xgl.
- The X server does not have high-level information available to it, compared with the information made available to the compositing/window managers. For example, using our drop shadow example again, window manager hints will let applications tell the window manager not to shadow something (say, the gnome panel). An X server like Xgl is forced to resort to guessing (of course, sometimes window managers resort to guessing too since WM hints are often vague and implemented differently ;-). To give another example, consider the window border/contents synchronization on resize feature of luminocity. This relies on WMapplication communication to specify when a redraw has been completed so the WM doesn’t draw its borders to the screen until the application is redrawn, and compositing manager support to double buffer the change when its actually applied, removing the last little bit of flicker. If its even possible to do this in the X server, its going to require some serious hackery (with the emphasis on hack), and probably some guessing in addition.
- Loosely related to both #1 and #2, putting this stuff in the X server means you have to upgrade your xserver (or add some sort of effects plugin system to the xserver) to get changes to the visuals. It sort of defeats the idea of the X server as the low-level no-nonsense piece.
I would not take something I say here as authoritative! My knowledge of this stuff only scratches the surface. But many people have been saying even less informed things, so I wanted to get slightly more accurate info out there (esp. on online forum comments). Enjoy 🙂
