- From: Glen Huang <curvedmark@gmail.com>
- Date: Fri, 17 Apr 2015 13:34:36 +0800
- To: Brian Birtles <bbirtles@mozilla.com>
- Cc: public-fx@w3.org
> Are you referring to the times returned by the computedTiming member or the process of applying changes to target elements? In my mental model, keyframe effects pull times from its computedTiming member then apply changes to the target element. So by UA updating keyframe effects, I mean the latter. > The point is it doesn't really matter and implementations can do whatever suits them. Ah, this makes much more sense. I always felt kinda knee-jerked when describing how time values flow (top-down or bottom-up) in my mental model. > 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 gives implementations more room to experiment with different architectures that the spec writers didn't think of. Sounds reasonable. > 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?
Received on Friday, 17 April 2015 05:35:16 UTC