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

[Felix Bellaby]

On Tue, 2006-07-11 at 00:52 -0400, Kristian Høgsberg wrote:
> 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.

This can be essentially be done within the compositor. The current
absence of the texture_from_drawable extension in most environments
means that truely portable GL compositors currently have to copy from
the Xcomposite Pixmap into a texture using glCopyTexSubimage. This means
that the texture acts as a buffer between the Xcomposite Pixmap and the
visible screen. 

If the compositor restricts itself to using glCopyTexSubimage on the
damaged areas then this texture based buffering is relatively quick.
Delaying damage reporting until the application is ready to display
would mean that the texture would not be updated until the critical
moment, providing the desired double buffering. Since the texture always
contains a valid (if outdated) application image, there is no problem
arising from transparents, animations or ordinary exposures. 

Using glCopyTexSubimage over glBindTexImage might not be such a bad idea
in the long time if it gives us automatic double buffering across the
board at relatively little cost. It is likely that GPU based GL
implementations will have very major headaches with synchronisation
getting glBindTexImage to work any faster than damage based copying.

Felix

PS:

I have already implemented this approach in the glcompmgr compositor
that I posted recently. All that it is awaiting is a delay to the damage
reporting.

I am afraid that I developed glcompmgr on the nVidia prop. drivers for
my convenience and it has some work arounds for bugs in those drivers.
However, I actively adapting it to some open source GL implementations
and the ATI props.