GLX_EXT_include_inferiors (was Re: compiz on aiglx)
krh at bitplanet.net
Wed Mar 15 15:12:45 PST 2006
Andy Ritger wrote:
> I'm not sure if GLX_EXT_include_inferiors is the right
> solution to the problem:
> - As already mentioned, in X, subwindow_mode (ClipByChildren,
> IncludeInferiors) is a property of the GC; if we wanted a
> direct analog in GLX, then we'd want to make include_inferiors
> to be a property of the GLXContext. An FBConfig attribute is
> different than a property of a GLXContext. Unfortunately, it's
> not currently possible to specify arbitrary additional properties
> of a GLXContext (we've been thinking about an extension to add a
> glXCreateContextWithAttribs or some such, but nothing like that
> exists so far).
> - it would be unfortunate to bloat the FBConfig list with
> include_inferiors... this would effectively double
> everyone's lists of FBConfigs.
> - I expect most GLX implementations propogate drawable
> data (like cliplists) from X to GLX on a per-drawable basis.
> For different contexts (with different include_inferiors
> values) to render to the same drawable, implementations would
> need to track two cliplists per drawable: the ClipByChildren
> cliplist and the IncludeInferiors cliplist. In the best
> case, this will be cumbersome for implementors; in the worst
> case, this would preclude using things like window id
All valid arguments, but if we move the include inferiors setting to be
a GlxWindow attribute, wouldn't that solve the problems?
> It looks like Deron Johnson is already checking in code for the
> composite overlay window, which seems like a preferable solution.
I don't know that the overlay window is the preferable solution, but
yeah, it's definitely checked in now, it just feels like we're sweeping
the problem under the rug (in more than one sense :) ). But hey, that's
not a new approach in Xorg, and I never really wanted to push hard for
the include inferiors solution.
More information about the xorg