GLX_EXT_include_inferiors (was Re: compiz on aiglx)

[Ian Romanick]

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

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

This is similar to my suggestion of making this settable state
per-drawable.  I'd have to do something and code spelunking to determine
which would be easier for the existing open-source drivers.

> - it would be unfortunate to bloat the FBConfig list with
>   include_inferiors... this would effectively double
>   everyone's lists of FBConfigs.

I agree 100%.

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

What that really amounts to is adding one bit per cliprect.  That would
require some changes, but I don't think it would be to arduous.  I don't
know of any currently supported architectures that actually use a WID
buffer.  I know the 3dlabs hardware does, but...yeah...

> 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?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (GNU/Linux)

iD8DBQFEF2TzX1gOwKyEAw8RAm7VAJsHWH5W0CGVXB9E4PBaVys1dPv7KwCfTmLg
lgBSTwl0vIzsMAfCfEwLIMQ=
=dVUE
-----END PGP SIGNATURE-----