monitoring the contents of the screen -- bug#14648
otaylor at redhat.com
Fri Sep 12 14:12:55 PDT 2008
On Fri, 2008-09-12 at 13:58 -0700, Keith Packard wrote:
> On Fri, 2008-09-12 at 16:03 -0400, Owen Taylor wrote:
> > Without having full replay to the contents of
> > Keith's head when the spec was being written, we'll probably never know
> > for certain why its there.
> For reporting modes which don't include the whole region, there's no way
> to know what the result of subtracting a particular region will be. So,
> if you 'collect' a bunch of damage, then repair that, the client won't
> be able to know what damage remains without having something sent to it.
Case by case:
What's in the damage region and you don't already have yet is "in
flight" between the server and you.
If the damage region is larger than the last bounding box you
received, then a new bounding box is in flight. (The region may
be larger than the region that triggered the bounding box that
you received, but that doesn't matter.)
You don't know the damage region, so using the 'repair' version of
DamageSubtract doesn't make sense.
It seems very plausible on the surface that it's to prevent a race
condition of this type, but I can't find any race conditions that it
actually solves :-)
More information about the xorg