GLX_EXT_include_inferiors (was Re: compiz on aiglx)

[Ian Romanick]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Kristian Høgsberg wrote:
> Ian Romanick wrote:
>> Kristian Høgsberg wrote:
>>
>>> Overview
>>>
>>>     This extension introduces a new FBConfig attribute,
>>>     GLX_INCLUDE_INFERIORS_EXT.  Creating a context with an FBConfig
>>> that has
>>>     GLX_INCLUDE_INFERIORS_EXT set will prevent inferiors (child
>>> windows) from
>>>     clipping output to the drawable currently associated with the
>>> context.
>>
>>
>> Would it be possible to elaborate on this a bit?  I'm not really sure
>> what this is even intended to do or why anyone would want to use it.
>> This isn't to say that I don't think it's useful, more to say that I
>> don't get it.
>>
>> If I have window A and a child window B, what happens if I draw to
>> window A?  Does this just provide a guarantee that if B obscures pixel
>> x,y of A that I can later read back (e.g., using glReadPixels) x,y and
>> get the result that I drew?  Does this mean that result of drawing x,y
>> of A gets "broadcast" somehow to B?
> 
> The wording and the basic idea is taken from the equivalent X GC
> subwindow_mode value.  The default behaviour (ClipByChildren) for X
> rendering is that output is clipped to the child windows of the output
> window.  So if you're drawing to window A and the primitive you're
> drawing overlaps with the child window B, the overlapping part will not
> be drawn and the contents of window B remains untouched.
> 
> If you're instead using a GC that has the subwindow_mode value set to
> IncludeInferiors, drawing to the parent window will not get clipped to
> the child windows, in effect rendering over the child windows as if they
> weren't there.  There is no way you can get this with behavior with GL,
> it always operates in ClipByChildren mode.

In the GL spec, this is the "pixel ownership test."  The rules are
actually a bit more flexible than that.  If a window overlaps, the
obscured pixels may or may not pass the pixel ownership test.  The rules
allow for implementations like X.org where all windows share the same
rectangle of memory.  It also allows for the case where each window has
it's own, private rectangle of memory that gets composited together for
display.

> glReadPixels will return whatever pixels are in the window, wether they
> belong to subwindows or not and wether they were drawn with
> IncludeInferiors or not.  I think.

I'd have to look, but I believe the spec says something like pixels
fetched using glReadPixels that did not pass the pixel ownership test
are undefined.  You might get some other window, you might get black, or
you might get pictures of granny.

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

*lightbulb*

Ah.

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.

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?

> The first draft has the IncludeInferiors as a context attribute, because
>  it a X GC attribute, and I just copied that at first.  But as David
> mentions this is probably better implemented as a GlxWindow attribute.
> Which we don't have atm in Xorg glx, but that's one part of glx 1.3
> that's pretty easy to add support for.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (GNU/Linux)

iD8DBQFEFguJX1gOwKyEAw8RAkCgAJ4jnUXmKSxmV9CW/Z5mXtS0NJSgJgCghOTR
dQs6UuyUy4Fa7c6Higw+LZw=
=KY6U
-----END PGP SIGNATURE-----