[RFC v2] Wayland presentation extension (video protocol)

Pekka Paalanen ppaalanen at gmail.com
Wed Feb 12 23:54:58 PST 2014


On Wed, 12 Feb 2014 11:27:12 -0800
Bill Spitzak <spitzak at gmail.com> wrote:

> 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".

That is exactly how I think of it, a frame period begins at time P[n].
The tick of P[n] is not in the middle of a frame period, it is at the
*beginning* of the frame period. The same for the T ticks, they mark
the intended begin time, IOW the presentation time.

> Therefore I see your
> scheme as "you are required to add T/2 or you will be early".

No.

> I believe it would be less confusing to describe the algorithm as
> start times rather than middle points, primarily because it will line

It *is* described as start times.

> up your 'P' points with the green lines, and because it makes it

The green lines are NOT frame boundaries. The green lines give the
range that gets rounded to a particular stating time P. Guess I should
not have made them vertical, but triangles with the peak at the tick
P[n].

> 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.

All timestamps are starting times already.

The only thing being at a mid-point (a green line) is where the result
of the rounding switches from one P to another.

- pq

> 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.



More information about the wayland-devel mailing list