- From: Brian Birtles <bbirtles@mozilla.com>
- Date: Tue, 21 Apr 2015 10:40:37 +0900
- To: Glen Huang <curvedmark@gmail.com>
- CC: public-fx@w3.org
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.
Received on Tuesday, 21 April 2015 01:41:04 UTC