XDamage extension over-reports window damage
keithp at keithp.com
Wed Feb 2 16:49:46 PST 2005
Around 16 o'clock on Feb 2, Jonathan Lennox wrote:
> Thus, for damage to windows, I clip the region of damage reports, based on
> the window's clipList or NotClippedByChildren regions and the relevant GC's
These clip lists correspond to the area of the window's pixmap covered by
the window, and so they work in the presense of the Composite extension.
> I'm not positive this is correct for the two render damage operations
> (damageComposite and damageGlyphs),
There's a subWindowMode in the Picture matching that in the GC, making
these exactly comparable.
> or for the Composite extension,
Composite is fine; it adjusts the window clipping regions to make sure
clipList and NotClippedByChildren match the area which will hold pixels
cooresponding to the window contents.
> or for calls to DamageDamageRegion made outside of miext/damage/damage.c.
There aren't a lot of those, and I think it's probably better to just
leave them alone for now. An enumeration might be useful so we could
track where it's being used.
> I'm also not certain what happens for windows with a backing store.
That's why the existing Damage code doesn't use the clipList region.
The current backing store code needs to be discarded and replaced with
Composite both so that it's more efficient and also so that it matches the
semantics required by the X specification.
I think for now we'll have to just use the existing mess when windows have
backing store. We can eliminate that code when we replace the backing
store code with a Composite-based implementation.
> What do you think? If you'd like, I can file an enhancement request in the
> freedesktop bugzilla with this patch.
Sure; let's get the backing store issues resolved before that though.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 228 bytes
Desc: not available
More information about the xorg