Performance change from X in Fedora Core 4 to Fedora Core 5

[Kristian Høgsberg]

On 7/10/06, Keith Packard <keithp at keithp.com> wrote:
> On Mon, 2006-07-10 at 22:41 +0100, Felix Bellaby wrote:
>
> > What we should be aiming to do is avoid the generation of damage reports
> > until we are ready to display the finished drawing. The compositor will
> > ignore drawing operations until the damage is reported, allowing the off
> > screen pixmap to act as a buffer. Then the compositor will set about
> > displaying the pixmap when the damage is reported, effectively
> > performing a buffer swap. Compositors already do this automatically so
> > you are not putting any extra burden on them whatsoever.
>
> Oh, that's an interesting notion, and it should be reasonably easy to
> implement as well. Just some kind of 'damage suspend'/'damage release'
> requests should be more than sufficient here. Adding that to Damage
> itself might be a reasonable option. Fixing Composite to let
> applications know when they are redirected might also be nice; right now
> there's no indication at all.

I agree with Raster here that for this use case it doesn't make sense
to suppress damage events.  Maybe there's another use case where it's
useful, but don't add it for this case.  The compositor can need
consistent, complete pixmaps for each window at any time. Moving
another window around, animations, anything.  Suppressing damage event
resulting from the application drawing only prevents the compositor
from recompositing the application pixmap because of those events, it
can still need to do so for other reasons.

So to acheive instananous, flicker free updates, there are two ways to
go:either block the compositor from doing any recompositing while the
application is updating it's pixmap (this requires protocol between
the application and the compositor, suppressing damage events doesn't
cut it), but this obviously suck because the whole screen freezes
every time any application redraws.  Similiarly, the compositor needs
to block all applications from updating their pixmaps while it
recomposites the screen.

The other option is to render to an off-screen pixmap and copy that
into the window contents once the application finishes drawing.  This
gives you instantaneous, atomic updates without blocking either the
compositor or the applications.  It does require the allocation of an
extra pixmap, but realize that this just a transient allocation that
goes away once the new contents have been copied to the composite
backing pixmap.  All things considered, I'd say this is the best
possible strategy for double buffering in a composited environment,
and incidentally, it's exactly what GTK+ does.

cheers,
Kristian