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

[Adam Jackson]

On Wed, 2013-10-09 at 00:42 -0700, Keith Packard wrote:
> 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.

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