On Wed, 2013-10-09 at 00:42 -0700, Keith Packard wrote: > 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.
This much is correct. The damage record exposed over the protocol is the client-visible geometry. > 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)). Enh. I'm not convinced. damageDamageAppend already clips based on subwindow mode, so you're either getting the borderClip if IncludeInferiors - thanks to NotClippedByChildren - or the clipList which includes children. And since we're in Xinerama, borderClip is already clipped to the containing ScreenRec's geometry. So we're not going to over-report on initial events. On subsequent subtract we wouldn't clip to the window, but... > 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. This is sort of true of non-Xineramified damage as already written, no? We're already not wrapping MoveWindow and friends in miext/damage. Subtract would magically trim off bits that had been configured away in the re-emitted report, but the 'parts' region is the region before reconfigure. > 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? It's just "union of borderClip for all backend windows", right? Or at least that'd be consistent with how DamageSubtract already clips in the non-xin case. That seems easy enough. - ajax _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
