[Mesa3d-dev] GLX and Xgl
davidr at novell.com
Tue Apr 12 12:15:39 PDT 2005
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:
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
More information about the xorg