Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[css-animationworklet] Consider adding callback to notify Animators when currentTime affecting params (e.g, finish/reverse/playbackRate) change #811

majido opened this issue Aug 29, 2018 · 2 comments
css-animationworklet-1 CSS AnimationWorklet API


Copy link

majido commented Aug 29, 2018

From @majido on July 21, 2017 1:56


The web animation's timing model is "stateless" with a notable exception of methods which change the timing properties such as finish, or pause.

Worklet animations deviate from this timing model to enable effects that are script-driven, stateful, and runnable in a parallel worklet execution context. In particular a worklet animation output is not only dependent on its time input but also its internal state. As such the worklet animations may not necessarily be amenable to constant time seeking and direction or rate agnostic playback.

However it is desirable to make worklet animations conform to the existing Animation interface as much as possible. This include finish method which seeks a particular time, or reverse method and playbackRate attribute that change playback rate.

Idea 1 - allow author defined behavior

Any methods that seeks a time or changes playback rate would cause a corresponding callback to be called on the corresponding animator in the worklet context. The user script will be responsible to provide best possible mapping for the given effect.

Here is a strawman API:

registerAnimator('foo', class {
  animate(timeline, output) {
    if (this.finished)
     output.localTime(timeline.time * rate * Math.rand());  
  finish() {
      this.finished = true;
  reverse() { 
    console.warn("foo animation is not reversible") 
 playbackRateChanged(rate) {
    this.playbackRate = math.abs(rate);


  • Authors has to work hard to "Do the Right Thing".


  • If the animation is stateless, this is too much work that could have all been done automatically. See next proposal.

Idea 2- modify the timeline.currentTime

We can modify the timeline.currentTime to reflect the seeked value and playbackRate.


  • Works fine for stateless effect.


  • Most likely the wrong behavior for any stateful effect. We will probably still need to do callbacks as well so that the animation can adjust accordingly.


There may be an elegant solution that sits somewhere between these two proposals where we do the stateless animations are automatically doing the right thing without a lot of boilerplate without it negatively affecting the stateful animation case. But I am not sure what it is. Ideas?

Even we don't find that elegant solution. I am inclined to go with idea 1 in particular because 1) I think it is appropriate for AnimationWorklet API to be slightly biased toward addressing the more complex stateful usecase 2) It provides more power on top of which we can add additional simplifying sugar in future.

Copied from original issue: WICG/animation-worklet#63

Copy link
Contributor Author

majido commented Aug 29, 2018

From @birtles on July 26, 2017 2:14

In general I think it's less of an issue for Animations to be stateful, and mostly an issue for their source content.

I didn't quite follow idea 2, however. Would an approach like the following work:

Timeline time(s)

Some function that produces a scaled single timeline time

Regular Animation timing calculations

Is that what idea 2 is proposing? What are the use cases where that would be unsuitable?

In terms of notifying state changes, I suppose one option is a React-like shouldComponentUpdate API where the default implementation simply compares the values of all timelines the animation is attached to. You'd still need to call that on every frame, however, which is not good.

I'm not sure how hard this is to do with worklets but if we could instead have more of a setState like API, i.e. something you call each time your worklet's state has changed, that would be better. Then the UA would just call animate() each time any of the worklet's attached timelines changed or it had been notified that the worklet's state had changed.

@majido majido added the css-animationworklet-1 CSS AnimationWorklet API label Aug 29, 2018
@majido majido changed the title Define semantic of finish/reverse/playbackRate for Worklet Animation [css-animationworklet] Define semantic of finish/reverse/playbackRate for Worklet Animation Aug 29, 2018
Copy link
Contributor Author

majido commented Mar 7, 2019

Note that the animator instances now get the "currentTime" of the animation which already contains calculations for playback rate and direction. This means that animators that only depend on currentTime would work as expected.

We still may want to provide a callbacks on the animator so that they can react to such changes without having to monitor currentTime.

@majido majido changed the title [css-animationworklet] Define semantic of finish/reverse/playbackRate for Worklet Animation [css-animationworklet] Consider adding callback to notify Animators when currentTime affecting params (e.g, finish/reverse/playbackRate) change Mar 7, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
css-animationworklet-1 CSS AnimationWorklet API
None yet

No branches or pull requests

1 participant