Re: [Mesa3d-dev] [mesa patch 1/3] dri2: Event driven buffer validation.

[Michel D. <mi...@da...>]

On Fri, 2010-01-22 at 13:33 +0100, Francisco Jerez wrote: 
> Michel Dänzer <mi...@da...> writes:
> 
> > On Fri, 2010-01-22 at 00:10 +0100, Francisco Jerez wrote: 
> >> Michel Dänzer <mi...@da...> 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.
> 
> That shouldn't happen, we only get InvalidateBuffers events when the
> client is actively processing X events: sane clients don't do that "in
> the middle of a frame" -- and whoever is actually doing that is likely
> to be prepared to deal with a resize and some invalidated buffers at the
> same point.

Ah, I didn't realize that, thanks for the clarification. Sounds good
then.


-- 
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer