GLX_EXT_include_inferiors (was Re: compiz on aiglx)
aritger at nvidia.com
Wed Mar 15 15:33:44 PST 2006
On Wed, 15 Mar 2006, Kristian Høgsberg wrote:
> 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
> > buffers.
> All valid arguments, but if we move the include inferiors setting to be
> a GlxWindow attribute, wouldn't that solve the problems?
Yes, making IncludeInferiors a drawable attribute would definitely
avoid the FBConfig bloat. It wouldn't be a direct parallel to the
subwindow_mode X GC property, but it's not clear how important
that is. The ClipByChildren/IncludeInferiors cliplist management
is probably the same if IncludeInferiors is a drawable attribute or
an FBConfig attribute, but that's workable, just a bit cumbersome
> > 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.
:) Let's see what Deron has to say about the composite overlay
More information about the xorg