[Mesa3d-dev] Re: GLX and Xgl
David Reveman
davidr at novell.com
Tue Apr 12 12:16:34 PDT 2005
On Tue, 2005-04-12 at 10:18 -0700, Ian Romanick wrote:
> David Reveman wrote:
>
> > The problem is that with Composite extension present a drawable can at
> > any time be redirected to a pixmap. So what do we do if the native GL
> > stack can't handle this? With framebuffer objects available we can
> > probably always allocate another texture and redirect drawing to it, the
> > native GL stack will handle software fall-back if necessary. What do we
> > do when framebuffer objects are not available?
>
> When an XVisualInfo is used to create the context (i.e., using
> glXCreateContext) and the pixmap (i.e., using glXCreateGLXPixmap), the
> context *MUST* support rendering to a pixmap. When using the fbconfig
> interfaces, there is a bit in the fbconfig that specifies whether or not
> the fbconfig can be used with a pixmap.
>
> So, if you make the following call:
>
> const int attribs[] = { GLX_DRAWABLE_TYPE,
> GLX_WINDOW_BIT | GLX_PIXMAP_BIT,
> None };
>
> ...
>
> configs = glXChooseFBConfig( dpy, screen, attribs, & num_configs );
>
> The fbconfigs you get back, if any, will all support creating contexts
> that can render to both windows and pixmaps.
>
> I think it is perfectly reasonable for us to require that, in addition
> to the other requirements for available fbocnfigs, any implementation
> support at least one fbconfig that meets those requirements. This is
> especially true since rendering to pixmaps already has to be supported
> for the pre-1.3 GLX interfaces.
>
> You can be 90+% sure that nobody will hardware accelerate rendering to
> pixmaps. Of course, that doesn't seem to be a problem for you anyway. ;)
>
That's a GLX specific solution. I definitely don't want that. It would
mean that we can't run Xgl on top of a window system that doesn't have a
fully working alternative to glXCreateGLXPixmap.
-David
More information about the xorg
mailing list