Top-most windows

[Deron Johnson]

Keith Packard wrote On 01/10/06 17:04,:
> On Tue, 2006-01-10 at 09:41 -0800, Deron Johnson wrote:
>
> Given the existance of GLX APIs based on FBConfigs, and the potential to
> additional modify GLX to enable IncludeInferiors rendering, it seems to
> me that all of our discussions should now be focused on mitigating the
> effect on a GL-based compositing manager in the short term. 

I'm not particularly enamored of this approach because I see it as
taking a long time to come to fruition. There are many drivers which
will have to be upgraded and many people and companies from which we
will need buy in. I can see this process easily taking 6 months or more
and even then there will always be some residual devices for which
support is not provided or is late in coming. In my mind, relying on
other people and processes to make the composite extension truly usable
is not a particularly agile strategy. Keep in mind that Windows Vista
will be shipped with these capabilities in the latter half of this year.
In the meantime people who build 3D window systems will have to continue
to hack their own copy of Xorg, and will probably need these hacks
indefinitely in order to support those devices who don't yet support
the GL mods. It almost forces a code fork. Too bad considering that all
of this could be avoided by adding a few lines of code to implement
a composite priority window. It's really quite simple and is not a
very significant amount of code to support. It also will provide
support for non-GL based compositing managers, such as ones based
on imaging libraries. Your GL-only-based solution does not address
this issue at all.

But if you are firm in wanting to pursue this approach then we will
still need a solution to the DID rendering problem. And we will also
need an effective way of disabling the display of all X cursors (even
grab cursors). And we will also need a way to stop uncaught events
from percolating up the tree and back into the input redirection
manager. After implementing fixes for these issues the composite
window changes will seem benign in comparison.

> The additional motivation for this position is that Mesa cannot today be
> used as a GL-based compositing manager; it has no way of redirecting GL
> rendering to arbitrary off-screen buffers. So, we have no credible free
> software solution which can take advantage of any of the proposed
> changes in any case. And, the changes necessary to make Mesa able to be
> used in a GL-based compositing manager happen to be reasonably well
> associated with the changes needed to make it possible to draw to the
> root window, leading me to conclude that in waiting for Mesa to be able
> to draw to off-screen buffers, we will simultaneously gain the ability
> to draw to the root window, leaving any changes introduced at this time
> dead weight that will exist for time eternal in our code base.

I see no reason to artificially couple this feature with the feature
of making GL render to off-screen buffers. Other than the fact that
they are both changes to the same code they have no design or
implementational relationship with each other. Priority-wise, it is
much more important to solve the composite manager output window
problem.