[Mesa3d-dev] GLX and Xgl

[David Reveman]

On Tue, 2005-04-12 at 08:52 -0700, Ian Romanick wrote: 
> 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.

I know that.

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

I don't want them to implement it. I'll implement it, inside Xgl.

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

I'm all for EXT_framebuffer_object, it's the key to the success of Xgl.
It's going to be used inside Xgl for all offscreen drawing. But I don't
see how EXT_framebuffer_object will help for a client that needs to bind
a window system drawable to a texture.

I want the compositing manager to be able to do something like this for
every redirected window:

GLuint texture;
Pixmap pixmap;

glGenTextures (1, &texture);
pixmap = XCompositeNameWindowPixmap (dpy, redirected_window);
glBindTexture (GL_TEXTURE_2D, texture);
glXBindTexImageARB (dpy, pixmap);

and then be able to draw the desktop using these textures. 

Is it possible to do this just using EXT_framebuffer_object? I don't see
how.

-David