On Sam, 2010-10-30 at 12:36 -0700, Keith Packard wrote:
On Sat, 30 Oct 2010 18:07:19 +0200, Michel Dänzer mic...@daenzer.net wrote:
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
On Fre, 2010-10-29 at 12:21 -0700, Eric Anholt wrote:
On Fri, 29 Oct 2010 10:46:00 +0200, Michel Dänzer mic...@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
On Sat, 30 Oct 2010 18:07:19 +0200, Michel Dänzer mic...@daenzer.net wrote:
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.
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
On Fri, 29 Oct 2010 10:46:00 +0200, Michel Dänzer mic...@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
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.
Bug #30260. Fixes the compiz wallpaper plugin with
On Thu, 28 Oct 2010 20:46:22 -0700, Eric Anholt e...@anholt.net 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
