Does composition render double-buffering useless?

[Felix Bellaby]

Carlos Eduardo Rodrigues Diógenes wrote:
> > > displayed on screen.  Most compositing managers listen for damage
> > > events on the off-screen pixmaps and recomposite immediately when
> > > damage occurs.
> > But don't they use some heuristics to optimize the composition step?
> > I imagine that composition after every simple damage (line, small
> > rect, ...) would damage performance quite a lot.

Compositors do not get a chance to react to every single piece of damage
as it happens. Damage accumulates while the compositor is drawing frames
and there is inherent latency between damage occuring and the compositor
reading it off its event queue. Furthermore, double buffered
applications only report damage when they swap buffers, hiding the
individual drawing operations from the compositor completely. 

> > 
> > I'll do some tests, maybe this could be made optional ... if the users
> > wants this, he/she gets it ;)
> > However I guess this could lower performance ... since more damage
> > situations eventuelly have to be handled. Nothing is as easy as it
> > seems ;)
> 
> When you are reading from the Xlib event stack you could know if the
> Damage event that you receive is the last one, if not, you could read
> the next and union the regions that was damaged. Only after you read all
> the damage events you update the screen.

Compositors normally exhaust their event queues before they begin
drawing a new frame. You could code a compositor to wait for a while
between frames to reduce their load on the system. However, the
resulting display might appear irratic due to the enforced delays
between the application and the user.

In any case, efficient compositors should only draw the damaged areas
between frames. This substantially reduces the impact of reacting to
damage as quickly as possible.

Felix