monitoring the contents of the screen -- bug#14648

[Keith Packard]

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.

> I don't think it can just be struck out of the spec, however. Even if
> nobody relies on it, the damage extension has been widely deployed and
> used, and making incompatible changes to semantics would go against
> reasonable maintenance policies.

Having a new 'update mode' that change the reporting policy would be
fairly simple.

> Another level also doesn't make sense to me, since re-reporting of
> left-over damage is really completely orthogonal from level.. it occurs
> at all levels. If my above suggestions aren't enough to resolve the
> problem, I think a fix would probably adding another option to the
> Damage object for that.

Right, think about the 'optimal' level for compositing managers -- you
get an event when the first damage is added, then you clean up 'all' of
the damage, if you didn't manage to clean it all up, you get another
damage event.

I'm good with most anything; it's clear that the current semantics
aren't what some people want.

-- 
keith.packard at intel.com
-------------- 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: <http://lists.x.org/archives/xorg/attachments/20080912/2a09410d/attachment.pgp>