[PATCH 2/2] damageext: Xineramify (v4)

[Keith Packard]

Aaron Plattner <aplattner at nvidia.com> writes:


> damageproto.txt doesn't seem to say anything about the region being 
> clipped so this seems fine to me, but Keith should probably be the final 
> arbiter on that.

Ok, I think I have some idea of what's going on.

Essentially, DamageSubtract wants to tell clients about the remaining
damage in the window after the region provided has been
subtracted. That's necessary as clients may copy the damage region,
repair it, and then DamageSubtract the copy from the window. Damage
added after the copy wouldn't be detected in some reporting modes, hence
spamming the client with the remaining region.

Ok, so what does the proposed change do to this? It may end up
over-reporting damage to non-visible regions (areas of the window which
aren't getting stored (either on the screen or in the off-screen
Composite buffer)).

The problem here is that damage is only clipped to the window when it is
merged in; if the window is reconfigured later, the damage is not
adjusted, so the damage may indeed contain areas which are not in the
current window clip.

The only concern I have is that a client which repairs only the damage
which is visible may end up leaving junk in the damage region from some
previous reconfiguration adventure, and could, in theory, endlessly
receive damage events for areas outside of that visible area.

How hard would it be to walk the screens and construct a complete
visible region for the window?

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20131009/ef3aeb96/attachment-0001.pgp>