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. Roland ------------------------------------------------------------------------------ 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
