Roland Scheidegger wrote: > On 21.08.2009 11:45, Tom Cooksey wrote: >> Hello, >> >> I'm a Qt developer. >> >> We want all Qt rendering to be done using OpenGL 2. We have this working >> pretty well (a few artifacts still here and there). However, we've found >> some >> fundamental problems using GL for regular widget rendering. Normally I >> wouldn't bother this list, but I've recently seen that someone's writing a >> new >> GL back end to Cairo, so I guess those guys are going to hit the exact same >> issues. >> >> The problem is partial updates. From what we've seen it's typical for >> applications to only update a small region of their top-level-widget at a >> time >> (E.g. a flashing cursor in a text edit). As Qt only creates a single X >> window >> per top-level widget, this means a sub-region of a single X window. >> >> 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. I notice there's an EGL >> implementation >> being worked on in Mesa trunk so perhaps we should switch to EGL rather than >> glX? >> >> Anyway, lets assume that swap buffers keeps the contents of the back buffer. >> There's another issue, although not as detrimental as the first. When we >> issue >> swap buffers, glX/EGL has to assume the entire window's contents has >> changed. >> That has 2 effects: 1) XDamage regions are generated for the whole window: >> When >> a composition manager is running, this means it has to re-compose the entire >> window, even though only a few pixels may have changed (which it might have >> to >> do anyway, see above :-)). 2) I'm led to believe that DRI2 implements swap >> buffers as a blit and so must blit the entire back buffer to the front. >> >> 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. 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). >> >> It seems like a glXSwapPartialBuffers which takes an array of dirty rects >> would >> be preferable. The implementation could ignore the rects completely if it so >> chooses or only use them to generate the damage region. Or, if it's on DRI2, >> it can choose to only copy the sub-region from the back to the front. >> Eventually it could also use the rects as a metric to figure out if it >> should >> flip or blit (flip if there's >30% region changed, blit otherwise). >> > > Would glx_mesa_copy_sub_buffer help? It only takes one rect though, not > a list.
BTW, a region of the back buffer can be copied to the front buffer with glCopyPixels() or glBlitFramebuffer() too. -Brian ------------------------------------------------------------------------------ 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
