GLX_EXT_include_inferiors (was Re: compiz on aiglx)

[Ian Romanick]

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

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.

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"?

/me still has some confusion...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (GNU/Linux)

iD8DBQFEFit7X1gOwKyEAw8RAi2DAJwIJz+//LvQCd5e6SCNivofTu4zoACeMe3t
OjHx05LomIoWgsNm0lGZy3U=
=s+De
-----END PGP SIGNATURE-----