[css-houdini-drafts] Define semantic of finish/reverse/playbackRate for Worklet Animation

majido has just created a new issue for https://github.com/w3c/css-houdini-drafts:

== Define semantic of finish/reverse/playbackRate for Worklet Animation ==
_From @majido on July 21, 2017 1:56_

# Problem
The web animation's timing model is ["stateless"](https://w3c.github.io/web-animations/#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](https://w3c.github.io/web-animations/#the-animation-interface) 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:

``` javascript
registerAnimator('foo', class {
  animate(timeline, output) {
    if (this.finished)
     output.localTime(10);
    else 
     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);
 }
}
 ```
Pros:
 - Authors has to work hard to "Do the Right Thing".

Cons:
- 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. 

Pros:
 - Works fine for stateless effect.

Cons:
 - 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.  


# Conclusion
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_

Please view or discuss this issue at https://github.com/w3c/css-houdini-drafts/issues/811 using your GitHub account

Received on Wednesday, 29 August 2018 18:19:19 UTC