On Fre, 2010-10-29 at 12:21 -0700, Eric Anholt wrote: > On Fri, 29 Oct 2010 10:46:00 +0200, Michel Dänzer <[email protected]> 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.
[...] > 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. Right, but as long as there's at least one rendering operation in between, at that point EXA will synchronize the pixmap copies according to the accumulated pending damage. That's the assumption broken by your change. Though I agree some of the cases you're changing may not have been 100% correct before, and introducing another mechanism for handling damage not directly related to rendering should fix that (and as a bonus avoid superfluous synchronization between EXA's pixmap copies). So I still think that would be the proper solution. -- Earthling Michel Dänzer | http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
