GLX_EXT_include_inferiors (was Re: compiz on aiglx)

[Kristian Høgsberg]

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