GLX_EXT_include_inferiors (was Re: compiz on aiglx)

[Andy Ritger]

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
for implementors.

> > 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
window approach.

Thanks,
- Andy


> Kristian
> 
>