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

[Eric Anholt]

On Fri, 29 Oct 2010 10:46:00 +0200, Michel Dänzer <michel at daenzer.net> wrote:
> 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.

Breakdown of the actual changed locations here:

compalloc.c:
        notification to trigger recomposite on transition to
        automatic compositing.

compwindow.c:
        1) client notification of damage after optimized-out noop
        internal rendering (introduced with original import of
        composite, I'm not clear on why it's needed)
        2) client notification of damage to trigger a redraw.

damageext.c:
        1) client notification of full damage in new damage struct on a
        window to trigger a redraw
        2) adding damage to a drawable *for direct rendering that has
        already occurred*

exa.c:
        Noop, replacing two function calls with the right one.

glxdri:
        Noop, replacing two function calls with the right one.

xf86Rotate.c:
        full damage on new shadow to trigger full shadow redraw later.

Without this change, you'll still get the "pending" damage reported at
some later date when other damage occurs to the pixmap that triggers a
processing of pending damage, completely disconnected from when the
rendering occurred, if any was involved.

This just brings the reporting in to when it's supposed to happen,
because either the rendering has already happened or it's a
communication mechanism between the server internals and compositing
(either automatic or manual) to trigger a redraw so that EXA has some
actual rendering (which will, itself, produce damage for actual
rendering).  I can't see how this would make EXA any more broken.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20101029/1f7f1827/attachment.pgp>