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

[Felix Bellaby]

On Mon, 2006-07-10 at 11:06 -0400, Owen Taylor wrote:
> - in the composited architecture, there already *are* persistent double
> buffers for all toplevel windows, so investigating using those in some
> way could be interesting. What you have to avoid is the compositing
> manager doing tons of extra work in this case.

Back buffering within applications & toolkits should almost certainly be
avoided when a compositor is running. The Xcomposite design buffers
everything that apps draw into offscreen pixmaps already and the
compositor may well be using a further layer of double buffering when
drawing those offscreen pixmaps onto the visible screen.

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.

Ensuring that damage is only reported when the app / toolkit is ready
for a buffer swap probably requires a suitable hook in the server that
performs the buffer swap operation. One might hope that the DBE
extension or a properly designed variation might do the job. 

The developers of the X server and its drivers can not be expected to
optimise the behavior of apps and toolkits that allocate pixmaps all
over the place. However, they could certainly make a stab at optimising
a consistent and sensible double buffering extension.

I understand that nVidia have left damage reporting for double buffered
GL drawing until glXSwapBuffers is called. I think that have things
right here.

Felix