Re: [web-animations] Sampling optimization

Hi Glen,

On 2015/04/15 15:37, Glen Huang wrote:
> If I understand the spec correctly, in the case of keyframe effects, an UA is expected to periodically update all keyframe effects.

I'm not sure exactly what you mean by updating keyframe effects. Are you 
referring to the times returned by the computedTiming member or the 
process of applying changes to target elements?

In either case, the way sampling is defined in the spec at the moment is 
definitely not accurate and I wouldn't pay much attention to it. I plan 
to fix that up sometime this quarter.

 > Upon being requested to update itself, a keyframe effect then queries 
the animation (who in turn queries the document timeline) to get time 
fraction and current iteration, and finally apply css properties or dom 
attributes to the target element accordingly.

The spec doesn't really dictate how this works, i.e. whether it's 
top-down or bottom-up etc. It's really up to the implementation.

For example, in my mental model the Animation pulls times from its 
AnimationTimeline and pushes them to its target effect. In Gecko that's 
how it works but I might change it so that timelines push times down to 
Animations. The point is it doesn't really matter and implementations 
can do whatever suits them.

> This whole process has one premise: the UA needs to periodically update all keyframe effects *unconditionally*.

In terms of observed behavior that's how it should appear to work (i.e. 
that on each animation frame, the state of each KeyframeEffect is up to 
date), but it doesn't need to be implemented like that as long as the 
observed behavior remains the same.

 > However in reality, the UA, after updating all keyframe effects, can 
check if any associated animation is still in running play state, if 
not, it can stop periodically updating keyframe effects all together. 
Only when an associated animation's play state become running (e.g., 
because a paused animation is played by a script), the UA then restart 
periodically updating keyframe effects. I wonder if this is how UAs will 
really implement it? After all, if all animations are currently paused 
(and only play when user clicks a button for example), keep periodically 
updating keyframe effects to reapply the same css properties or dom 
attributes over and over again is a waste of resource.

Right, implementations will avoid ticking away when there's no work to 
be done, especially if they're expected to run on mobile devices.

> This is at least how the web-animations polyfill work: when no animation is in running play state, it stops calling `requestAnimationFrame`.

Native implementations work the same way. 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.

> Could the spec be specified this way? So it's easier for everybody to correctly implement this optimization (e.g., when to stop and restart the periodical updating)?

I don't think the spec should do that. Unless the spec is requiring 
something that can't be implemented efficiently, it should describe the 
required behavior and leave it up to implementations to find an optimal 
way of achieving that. That gives implementations more room to 
experiment with different architectures that the spec writers didn't 
think of.

Having said that, I definitely think all the current references to 
"sampling" in the spec need to be rewritten.

Best regards,

Brian

Received on Friday, 17 April 2015 04:23:12 UTC