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

Carsten Haitzler (The Rasterman) raster at
Tue Jul 11 06:44:41 PDT 2006

On Tue, 11 Jul 2006 13:25:00 +0100 Felix Bellaby <felix at>

> 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. 
> When I made this comment I was hoping that _efficient_ compositors would
> be able to ignore the contents of "undamaged" sections of the off screen
> pixmaps. Unfortunately, transparent, actively distorting and unmapped
> windows would expose areas of windows behind them that had not been
> damaged. The compositor could not accurately determine the contents of
> those exposed areas from the Xcomposite pixmap if it was being used as a
> back buffer.
> Therefore, the approach to back buffering that I was proposing would
> rely on the compositor avoiding drawing undamaged areas that it did not
> need to draw (surely a good idea) _and_ finding efficient work arounds
> for exposures created by transparent, actively distorting and unmapped
> windows.
> I am uncertain whether the compositor would be the best place to try and
> work around the potentially complex effects of these exposures.

an intermediate copy would be needed - one way or another, and the only place
to really do it properly is in the original client doing the drawing - while
your idea is sound and a good idea in general - it does have holes as already
discussed. the only solution really is still a tmp pixmap for update regions. i
do think it is a nice idea to be able to batch up the damages in 1 foul swoop
to know then the damage events will be delivered in a very tight sequence the
compositor has the best chance of merging into a single update.

------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster at
Tokyo, Japan (東京 日本)

More information about the xorg mailing list