On Friday 21 August 2009 16:47:23 ext Michel Dänzer wrote: > On Fri, 2009-08-21 at 11:45 +0200, Tom Cooksey wrote: > > When using glX, we have no guarantee over what state the back buffer will > > be in after swap buffers. So, whenever an application needs to update, it > > must re- render the entire window. This makes things slow (we have to > > invoke every child widget's paint event). To overcome this, we try to use > > a 3rd buffer as a back buffer, usually a multi-sampled FBO or PBuffer. We > > direct rendering to the FBO/PBuffer, bind it as a texture (after blitting > > it to a non multi-sampled FBO if needed), draw the whole buffer to the > > window's back buffer then call swap buffers. Eughhh! But at least the > > PBuffer/FBO contents aren't destroyed. What would be really nice is to be > > able to have an EGL_SWAP_BEHAVIOR == EGL_BUFFER_PRESERVED equivalent on > > glX. > > There's the GLX_OML_swap_method extension, but I'm not sure how well > it's supported by our drivers at this point. Any issues there might not > be hard to fix up though.
I've taken a look at that extension, but all it tells you is if the driver will flip or blit, which is a different question to if the back buffer will be preserved after a swap. Some hw can provide buffer preserved behavior for flips and other hw seems to nuke the back buffer during the blit. :-( > > I think I can work around this by making a glx context current on a > > GLXPixamp (from a XPixmap). Pixmaps are single buffered and so don't get > > destroyed on swap buffers (in fact I don't even call swap buffers). I can > > then post updates using XCopyArea which will also cause the Xserver to > > generate an appropriate XDamage region for the compositor. The only down > > side is that I have to glFinish before calling XCopyArea. > > Actually you should only need glXWaitGL(), assuming the implementation > of that meets the requirements of the GLX spec. I'll give that a go, thanks for the tip! > > While I have this working, it seems a little hacky and isn't widely > > supported (I have it working on 1 driver build for 1 bit of hardware). > > If you mean rendering to pixmaps isn't widely supported, that should be > getting better with DRI2. I hope so. Although even with DRI2, I think my Intel drivers have broken pixmap rendering at the moment (although it could be Qt which is doing something strange). Cheers, Tom ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
