[Mesa3d-dev] GLX and Xgl
idr at us.ibm.com
Tue Apr 12 08:52:50 PDT 2005
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.
> 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.
More information about the xorg