[Mesa3d-dev] Re: GLX_EXT_texture_from_pixmap

[Brian Paul]

Adam Jackson wrote:
> On Monday 06 February 2006 07:58, David Reveman wrote:
> 
>>Hey,
>>
>>here's the latest version of the texture from pixmap spec that Xgl will
>>be supporting. It's not fully implemented in Xgl yet, just so much of it
>>that you can get an indirect rendering compositing manager running using
>>it.
> 
> 
> Regarding issue 5 (rebinding and texturing directly from the pixmap image), 
> I've suspected for a while now that we need some form of protocol whereby 
> apps can signal to the compositing manager that they've rendered a frame to a 
> given pixmap and therefore that it should be rendered from quickly.  Others 
> have proposed using sync counters as an even/odd toggle indicating whether 
> the pixmap is "baked" or not.  I think we want the ability to specify live 
> updates to the pixmap as an (optional) attribute to BindTexImage to 
> accomodate for this sort of handshaking in the future.

I think there's some implicit and explicit clues to indicate when 
drawing to a pixmap is completed.

With OpenGL rendering, the glFlush/glFinish() commands are used to 
force any buffered rendering commands to be completed (with the 
implication is the results are to be displayed immediately).  The 
SwapBuffers function does an implicit glFlush.

With Xlib rendering, any buffered rendering commands are supposed to 
be completed when any Xevent-getting function is called, or an 
explicit XFlush() or XSync() is used.

These would seem to be the signals to "push" rendering to the screen. 
  There's other times when the window system wants to "pull" images to 
repaint the screen.  In that case I think it's OK to get pixmap images 
that aren't completely rendered.  Sure, you may get some 
glitches/artifacts, but we've been living with that for many years. 
If the pixmap is _copied_ to a texture, though, you kind of get double 
buffering automatically.


> Other than that it's been fairly easy to hook this - well, "this" when it was 
> still called EXT_texture_from_drawable - up in the GLX implementation in the 
> xfree86 DDX, and we've been pretty pleased with the results so far.  I don't 
> see anything in this revision that will make life any harder in the xfree86 
> DDX.
> 
> Currently we're just doing TexImage2D to dump the bits from the pixmap to the 
> texture, which is suboptimal but works surprisingly well as long as your 
> pixmaps are in host memory (thank you, XaaNoOffscreenPixmaps).  In the future 
> there's probably some integration to be done with the GetImage path for 
> accelerated downloads, or with on-card copies from pixmap storage to texture 
> storage, or live updates as mentioned above.  Also in the medium-to-long term 
> we should look into unifying the GLX code between the xgl and xfree86 DDX's.  
> I haven't had the chance to look at the xgl side in too much detail, but I 
> expect there's some common themes.

-Brian