[RFC v2] Wayland presentation extension (video protocol)

[Bill Spitzak]

I think I was wrong to say the display time would always be >= to the 
time the client specifies. It would be rounded just like you are saying, 
the nearest start time would be rounded to the nearest output frame 
start time and thus could be earlier.

I tend to think of a "frame" as covering a period of time. Ie I don't 
say it is centered at a given time, instead I tend to think of it as 
*starting* at a time and having a "length". Therefore I see your scheme 
as "you are required to add T/2 or you will be early".

I believe it would be less confusing to describe the algorithm as start 
times rather than middle points, primarily because it will line up your 
'P' points with the green lines, and because it makes it easier to talk 
about actual wall time (ie the client cannot do anything about the past 
so this is a time that always describes a "start"). But I also believe 
the result will be an identical algorithm so if you think otherwise I 
don't really see a problem.

Special effects are rather inconsistent. For sound and computed motion, 
and often for motion blur they tend to think of the time being at the 
start of the frame. But keyframed animation and tracking tend to think 
of the time as being in the middle of a frame, primarily because the 
user wants to place something at a point, and not have to set two keys 
who's average is that point.

Pekka Paalanen wrote:

> Ok, so what you are suggesting here is that we should change the whole
> design to always have presentation come late with a mean delay of half
> the refresh period (T/2) and the amount of delay being between 0 and T.
> 
> Just like you say, then the client will have to arbitrarily guess and
> subtract T/2 always to be able to target the vblank at a P. Also note,
> that since presentation feedback reports the time P, not P - T/2, the
> clients really need to do the subtraction instead of just queueing
> updates with target time t = P + n * T.