On Fri, 2010-01-22 at 00:10 +0100, Francisco Jerez wrote: > Michel Dänzer <mic...@daenzer.net> writes: > > > On Sat, 2010-01-16 at 23:01 +0100, Francisco Jerez wrote: > >> When a buffer invalidation event is received from the X server, the > >> "invalidate" hook of the DRI2 flush extension is executed: A generic > >> implementation (dri2InvalidateDrawable) is provided that just bumps > >> the "pStamp" sequence number in __DRIdrawableRec. > >> > >> For old servers not supporting buffer invalidation events, the > >> invalidate hook will be called after flushing the fake front/back > >> buffer (that's typically once per frame -- not a lot worse than the > >> situation we were in before). > > > > When the invalidate event is available, IMO the buffers should also only > > be invalidated after a buffer swap / front buffer flush, not 'in the > > middle of a frame'. > > > Event-driven applications want the new buffers immediately after getting > the resize event, otherwise they could try to draw outside the bounds of > the old buffers, and that rendering would be lost.
I still don't see any benefit to changing the buffers while the app is rendering a frame, but I guess the problem is that the DRI2 code in libGL doesn't know if that's the case or not... > Patches 2 and 3 make the affected drivers fabricate a flush before > switching buffers, so the previous rendering shouldn't be lost either. That may help for the fake front but not for the back buffer. Then again I guess the worst case is intermittent incomplete frames during a window resize, which may be acceptable. -- Earthling Michel Dänzer | http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ------------------------------------------------------------------------------ Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
