Aaron Plattner <[email protected]> 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? -- [email protected]
pgpNVTaJpKJdz.pgp
Description: PGP signature
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
