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. -- [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
_______________________________________________ xorg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xorg
