New definition of duration adds new "next v-sync boundary" concept without further explaination

[mithro]

Nothing else in this document refers to "v-sync boundary" in any way.

startTime is defined in terms of the raf specification and I think we should also define duration in terms of raf spec. This means we have one specification which deals with v-sync boundaries which will make things much simpler when we get around to dealing with non-vsync enable displays, rendering for future time, etc.

I think we can do this by saying _the raf time which _would be used* if a raf callback was scheduled* to handle the case where there aren't actually any raf calls because there are no animations or raf functions registered.

I propose we should replace the following text;

The duration attribute must return a DOMHighResTimeStamp with the duration of the frame, computed by subtracting the startTime of the current frame from the next v-sync boundary.

With something along the lines of;

The duration attribute must return a DOMHighResTimeStamp with the duration of the frame which is the difference between the **end of a frame** and the startTime. The **end of a frame** is defined to be the next frame beginning time that would be used if a raf callback was currently scheduled.

After writing this, I also think the startTime probably needs a similar clause about being the time that would be given to raf if a callback was scheduled so it is also clear the what the value should be even when raf isn't running.

What do you think? @mbp @vmpstr @igrigorik

[igrigorik]

I think this a great cleanup and improvement. :+1:

The startTime attribute must return a DOMHighResTimeStamp with frame's beginning time value, which is the time that the animation frame request callback (see [Animation-Timing]) would have fired for the frame.

The duration attribute must return a DOMHighResTimeStamp with the difference between the end and the startTime of the frame. The end of the frame is defined as the beginning time of the next frame's animation frame request callback (see [Animation-Timing]), if such was scheduled in the current frame.

WDYT?

[mithro]

@igrigorik I'm not 100% sure, but I think your wording change my meaning ever so slightly?

When there are raf callbacks, the end time is the next raf callback value. When there are no pending raf callbacks, the end time is the value that raf would have taken if there had been raf callbacks.

I think we need to make the above as explicit as possible so there is no mistakes of just using the next raf value the next time raf is called.

[mpb]

so..

The startTime attribute must return a DOMHighResTimeStamp with frame's beginning time value, which is the time that the animation frame request callback (see [Animation-Timing]) would have fired for the frame.

The duration attribute must return a DOMHighResTimeStamp with the difference between the end of the frame and the startTime of the frame. The end of the frame is defined as what the beginning time of the next frame's animation frame request callback (see [Animation-Timing]) would have been, had one been scheduled in the current frame.

[igrigorik]

Let's continue this discussion on #32.