On 2015/04/17 14:34, Glen Huang wrote:
The difficulty for a JS implementation is to make sure the times reported by
the timeline etc. match up with the current frame even when the polyfill is not
listening for frames but something else is generating them
Yes, that's the difficulty I encountered. My current solution is to cache
performance.now() when the current time is requested for first time in this
event loop, and then clear it in a new task (so the current time stays the same
in the same event loop). Do you think it's a valid solution?
That sounds reasonable. There's some discussion about exposing the
"frame time" and "frame ID" to script in a future version of
requestAnimationFrame which would possibly make this even easier
(provided you don't have to register for requestAnimationFrame in order
to get it).
Having said that, I definitely think all the current references to "sampling"
in the spec need to be rewritten.
Looking forward to that. But since it won't address who pulls or pushes the
time values, I guess it only clarifies when the sampling happens?
That's right.
