Top-most windows

[Deron Johnson]

> It's not 'other people', the people doing DRI/Mesa are part of our clan
> and are actively working on this right now. We can help them even.

The people affected are definitely not "part of our clan." Many, many
companies implement OpenGL. There is Nvidia, ATI, Intel, Matrox, 3Dlabs,
and Sun, to name a few. GL is a much bigger beast than just Mesa.
Implementors of advanced window systems need to be able to run on all
of these GL implementations. Mesa-specific extensions are worthless
in this case.

> No changes in Xorg are required; we already have presented a workable
> architecture which an existing compositing manager has demonstrated.

What you have is a workable architecture only for the existing
compositing manager (I assume you are referring to the raise window
hack). But this architecture is not workable for desktop environments
that have more intense rendering requirements. This approach is going
to substantially reduce the frame rate of the composite manager
and impact the frame rate of animating X apps.

> Yes, we've already discussed a mechanism that disables the presentation
> of the cursor without destroying the cursor image information. I've
> suggested a few times that we should write an
> XFixesHideCursor/XFixesShowCursor that affects the presentation of the
> cursor within an entire window hierarchy.

Yes. I would definitely like to see such an extension.

> It's not an artifice; the reality is that Mesa is not ready today to be
> used in the architecture you're proposing. 

I think you're being too focussed on Mesa and are forgetting that there
are other GL implementations out there besides Mesa. It is unfortunate
that Mesa is not ready to be used by a composite manager (I disagree)
but every other GL implementation out there is ready. It only takes
a negligible amount of server code and every GL implemenation on the
planet that runs in X11 will work.

> We cannot composite the output of regular 3D applications into
> the scene because we cannot redirect those windows at all.

As I have said before, this has nothing at all to do with a composite
manager using GL to do its rendering. Nothing at all. I'm not sure
why you keep saying they are related when the only commonality
is that one needs to change the same library to make them happen.
There is no design or implementation dependency. The code is
completely separate.