monitoring the contents of the screen -- bug#14648

Keith Packard keithp at
Fri Sep 12 14:27:54 PDT 2008

On Fri, 2008-09-12 at 17:12 -0400, Owen Taylor wrote:
> 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:
>  DamageReportRawRectangles
>  DamageReportDeltaRectangles:
>   What's in the damage region and you don't already have yet is "in
>   flight" between the server and you.

Right, in this case, I think flooding the wire with extra rectangles
isn't useful.

>  DamageReportBoundingBox
>   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.)

In this case, you can discard the intermediate bounding box by sequence
number as you "know" a new event will be delivered with the right
bounding box.

>  DamageReportNonEmpty
>   You don't know the damage region, so using the 'repair' version of
>   DamageSubtract doesn't make sense.

In this case, you need to know whether there is any damage remaining,
the only way to know is to get the event after repairing some of the

keith.packard at
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <>

More information about the xorg mailing list