Does composition render double-buffering useless?

[Torgeir Veimo]

Felix Bellaby wrote:
> 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.

What about adding the possibility to obtain a heartbeat counter, so that 
an application can sync it's buffering to the compositor / screen-refresh?


-- 
-Torgeir