Top-most windows

[Keith Packard]

On Thu, 2006-01-12 at 11:48 -0800, Deron Johnson wrote:
> > 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.

I don't believe using FBConfigs for context creation in GLX is a Mesa
specific addition.

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

No, there will be no performance degradationn for other apps; there is
no need to grab the server during any rendering. Again, the visual
effect of a menu mapping on top of the stack during compositing is only
the failure to update that region of the screen. And, unless your
compositing manager is really slow, that won't happen very often.

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

I think this is a good candidate; we've got many potential compositing
managers that want to use a client-drawn cursor. I'm not sure when I'll
get a chance to look into this; I've still got that event redirection
paper due for LCA in a few days time...

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

Really? I was unaware that you could use X pixmap content as a GL
texture in any implementation, and redirect GL rendering to off-screen X
pixmaps. For Mesa/DRI, this is a huge change which I've been pushing for
several years.

>  It only takes
> a negligible amount of server code and every GL implemenation on the
> planet that runs in X11 will work.

Not for Mesa; we're talking a complete rewrite of the memory manager and
other critical bits. Sharing X pixmaps as GL textures is going to be
fun.

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.x.org/archives/xorg-arch/attachments/20060112/bf191c81/attachment-0001.pgp