[PATCH 1/2] Replace usage of DamageRegionAppend with DamageDamageRegion to fix reportAfter.

[Michel Dänzer]

On Don, 2010-10-28 at 20:46 -0700, Eric Anholt wrote: 
> In all these cases, any rendering implied by this damage has already
> occurred, and we want to get the damage out to the client.  Some of
> the DamageRegionAppend calls were explicitly telling damage to flush
> the reportAfter damage out, but not all.

I haven't been able to confirm it on some quick tests, but I suspect
this will break EXA in some cases, as it assumes that between a
DamageRegionAppend/DamageRegionProcessPending call pair the
corresponding region will be modified by a rendering operation and will
thus be valid in the current copy of the pixmap contents and invalid in
the other copy.

Maybe what's needed here is some other mechanism for specifying a region
that is not related to actual rendering but only to be reported to
clients via the DAMAGE extension for informational purposes.

FWIW, the test that prompted me to split up damage processing into two
steps was starting compiz in an xterm on an otherwise 'naked' X server.
The xterm window borders (the parts between the decoration and the
actual terminal contents) would previously be corrupted. I suspect this
change will reintroduce that problem with the EXA 'classic' scheme at
least.


-- 
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer