[Mesa3d-dev] GLX and Xgl

[Ian Romanick]

David Reveman wrote:
> On Mon, 2005-04-11 at 11:52 -0700, Ian Romanick wrote: 
>>David Reveman wrote:
>>
>>I haven't committed (or released as patches) any of this yet because 
>>it's pretty big, and I don't see a clear way to cherry-pick any parts of 
>>it out.  Pretty much all of my changes end up breaking GLX for Darwin 
>>and cygwin.  After looking at your xserver-glx.diff patch, I'll see if I 
>>can pull out my dispatch table changes.
> 
> It would be nice for me if we can get something like that into CVS soon.
> Even if it's just some temporary solution that we'll use until you're
> finished with the real thing that's fine with me.

Okay.  I'll see what I can come up with.

>>Can you elaborate on this more?  The reason I'm asking is that, with the 
>>advent of EXT_framebuffer_object, there is almost no chance that there 
>>will ever be a GLX_ARB_render_texture extension.  Even before 
>>EXT_framebuffer_object there were a few efforts to start a working group 
>>for that extension, and there just wasn't enough interest to get it going.
> 
> Sure.
> 
> Using the Composite extension and a GL based compositing manager for
> drawing the desktop is what we want. What a GL based compositing manager
> needs to be able to draw the desktop is top level windows as textures.
> Xgl already stores top level windows as textures so this can be very
> efficient with Xgl. What we need is some way for the compositing manager
> to bind an X drawable to a texture id in it's GL context. So we need a
> new window system dependent GL extensions for this. Accidentally this
> happens to be almost exactly what GLX_ARB_render_texture is supposed to
> do, maybe we can just use that extension now that we found a use for it.
> 
> I'm going to implement this in Xgl and we can then see what we want to
> do. New extension or use GLX_ARB_render_texture, doesn't really matter
> for me. But it's going to supply the functionality of
> GLX_ARB_render_texture either way.

But that was my point.  Go look in the extension registry.  There is 
*NO* GLX_ARB_render_texture.  It does not exist.  Because of that, I 
doubt that any implementation that doesn't already implement some 
version of this (I think Nvidia has something on Linux) is going to want 
to implmement it.  EXT_framebuffer_object, on the other hand, is quite 
likely to end up either as an ARB extension or in the core spec "pretty 
soon".  We just need more implementation & usage experience.