Re: [Dri-devel] New tdfx driver, locking, small device driver changes

[Keith W. <ke...@va...>]

Nathan Hand wrote:

> 
> We can't do that. Imagine the case where the span functions are writing
> some form of large slow blit (say a DrawPixels into a large region with
> many cliprects). If the X server gets any time then the user could move
> a window over the region then the clip rects could potentially change.

We already do.  We lock at the beginning of a span and unlock at the end. 
There is nothing new I'm proposing on this level.

> The result is the span functions are working on outdated clip rects and
> you get nasty screen corruptions.
> 
> This was what we had before and this is exactly why BEGIN/END_CLIP_LOOP
> were added. We were getting screen corruptions in the span functions.

BEGIN_CLIP_LOOP includes a call to LOCK_HARDWARE.  END_CLIP_LOOP calls
UNLOCK_HARDWARE.  

Old behaviour:

	LOCK_HARDWARE
	loop over current cliprects
		render span segment
	UNLOCK_HARDWARE

New behaviour:

	UNLOCK_HARDWARE
	LOCK_HARDWARE
	loop over curent cliprects
		render span segment

These are the same except that the first expects the lock not to be held on
entry/exit, the second one expects it to be held at those points.

Keith