[Mesa3d-dev] Re: GLX and Xgl

[David Reveman]

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