[PATCH weston 2/2] compositor-drm: Fix inconsistency in finish frame timestamps

[Bill Spitzak]

On 02/19/2013 03:16 AM, Pekka Paalanen wrote:

> http://blog.fishsoup.net/2012/11/28/avoiding-jitter-in-composited-frame-display/

That is really interesting but I think his first solution is what is 
needed, combined with multiple buffering, which in Wayland is done by 
the client.

In this diagram he shows the compositor performing at regular intervals 
(except skipping it if the current display is correct):

http://owtaylor.files.wordpress.com/2012/11/tweaking-compositor-timing-not-busy-wait-large.png

As I see it, the down-arrow from "Draw" to the Application is the 
buffer-release call.

The other call being discussed is not really shown there, it connects 
the "Swap" in the top line to the Application. I think it could be sent 
at any moment from the end of Draw to then end of the Swap. I think the 
discussion here is what happens if for some reason the swap does not 
happen or does not cause the result of draw to be visible. In that case 
this must not be sent, it should be sent only when it is absolutely 
certain the swap is going to work.

The timestamp should be at some point during or after the swap so it is 
close to when the user sees the new image. I don't think that can be 
really accurate as "when the user sees the image" includes portions that 
are implemented in the human brain, but the timestamp should be 
consistent, for instance it is always exactly the same number of 
milliseconds after vblank.

The paper also has this diagram showing it failing and making a program 
draw slower than it could:

http://owtaylor.files.wordpress.com/2012/11/tweaking-compositor-timing-busy-wait-large.png

I think the problem here is that it is trying to do single-buffering. In 
Wayland the application is entirely in charge of multiple buffering, and 
in fact has to do it: in this example if some other application caused a 
Compositor Draw in the middle of the Application Draw, Wayland would 
composite the partially-drawn image into the result.

If the Application started drawing immediately into the other buffer, it 
would cram all the brown "Draw" boxes in the bottom next to each other, 
and it looks to me like every other "Swap" in the top would be used.

So I see no reason for his idea of having "urgent" frames.