GLX_EXT_include_inferiors (was Re: compiz on aiglx)

[Andy Ritger]

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.

It looks like Deron Johnson is already checking in code for the
composite overlay window, which seems like a preferable solution.

Deron: how far along is the composite overlay window implementation?

Thanks,
- Andy



On Mon, 13 Mar 2006, Kristian Høgsberg wrote:

> Ian Romanick wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > Kristian Høgsberg wrote:
> >> Ian Romanick wrote:
> >>
> >>>> The motivation for the GLX_EXT_include_inferiors extension is that when
> >>>> rendering to the root window, even if the child windows (i.e. the
> >>>> top-level windows) have been redirected, they still clip output to the
> >>>> root window.  For a compositing manager to be able to use the root
> >>>> window to draw the desktop, we need a way to specify the equivalent of
> >>>> IncludeInferiors for GL rendering.  GLX_EXT_include_inferiors provides
> >>>> this mechanism.
> >>> Let me propose an alternate idea.  What you really want is to force the
> >>> pixel ownership test to always pass, right?  This would be analogous to
> >>> disabling depth testing or alpha testing.  It sounds like we want a
> >>> function like glXPixelOwnershipFunc that can take parameters like
> >>> ALWAYS, NEVER, ALL_WINDOWS, NON_CHILDREN.  If that's what we want, then
> >>> let's implement *that*. :)
> >>>
> >>> The beauty is that this would be really easy to implement for DRI
> >>> drivers.
> >> Indeed, the implementation is trivial, viz this patch I posted as one of
> >> the hacks to get compiz working on aiglx:
> >>
> >> http://freedesktop.org/~krh/compiz-on-aiglx/aiglx-gl-include-inferiors.patch
> >>
> >> The issue is how to control this.  A GlxWindow GLX_INCLUDE_INFERIORS_EXT
> >> attribute is a simple and non-intrusive way to set this, and if you're
> >> familiar with the X GC property, you'll immediately know what it does. I
> >> guess it as question of wether you're coming from the Xlib side of
> >> things or the GL side of things :)
> > 
> > Fair enough.  Although, I'm not convinced that making this a static
> > property of an X GC was the right design decision in the first place.
> > This really feels like a piece of drawing state that an app should be
> > able to enable / disable at will.
> 
> In the X case, what you could do is to keep a number of GC's around, one 
> with IncludeInferiors and one with ClipByChildren.  As far as I know, 
> this is a common Xlib idiom, at least gtk+ keeps a number of GC's around 
> with different settings.  For GL, you could do the same, though it seems 
> a bit more heavy-handed to have to keep multiple GL contexts around just 
> for this.  That just another reason why this might be better done as a 
> drawable attribute - that way it can be turned on and off using 
> glXChangeDrawableAttributes.
> 
> >>> In fact, we could even add a query so that an app can determine whether
> >>> or not a pixel ownership test happens (e.g., whether or not a drawable
> >>> shares memory with other drawables).
> >>>
> >>> So, here's my other question.  In this configuration, what happens if
> >>> you draw over top of some child window, and the application owning that
> >>> window calls glReadPixels.  Does it get garbage?
> >> I would think it gets whatever is in the framebuffer for that window. Is
> >> this a trick question? :)
> > 
> > It wasn't a trick question, but I think that was a trick answer.  I'm
> > just looking for clarification.
> 
> Yeah, sorry about that, it's just when I send the mail I thought it was 
> pretty obvious, but thinking about it again, I can see there's a few 
> more issues than in the X case.
> 
> > I'm a little uncomfortable with rendering in context being able to
> > modify the data in a drawable bound to another context, whether they're
> > in the same process or not.  That's counter intuitive, there's no way to
> > detect it, and is likely to cause problems for at least some apps in
> > unexpected ways.
> 
> It is an odd case in the X version too, but X does give you this and I 
> think the assumption is that since they're your child windows, you know 
> what you're doing.  I didn't realize that GL could be implemented in a 
> private-rectangle-of-memory-per-window mode where it composites the 
> subwindows over the parent window in a final step.  I can see how the 
> behavior in that case gets confusing.  Not sure how to handle that case...
> 
> > If all the windows are redirected, this won't be an issue, right?  The
> > window's buffers live "off-screen", over-writing the data in the
> > composited buffer won't impact the results of glReadPixels in the child
> > window.  However, if all the windows are redirected, I guess I don't
> > understand why you even need this.  Isn't the composite operation just
> > drawing a bunch of textures that happen to be other windows into the
> > screen's "window"?
> 
> Ideally, this wouldn't be a problem since once you redirect a window it 
> conceptually disappears from the window stack and doesn't contribute to 
> clipping or get clipped.  In reality, this is, to quote keithp, "hard", 
> and we're looking for the least ugly workaround...
> 
> > /me still has some confusion...
> 
> Well, me too now...
> 
> Kristian
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg
>