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

_From @birtles on July 26, 2017 2:14_

In general I think it's less of an issue for `Animation`s 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`](https://facebook.github.io/react/docs/react-component.html#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`](https://facebook.github.io/react/docs/react-component.html#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.

-- 
GitHub Notification of comment by majido
Please view or discuss this issue at https://github.com/w3c/css-houdini-drafts/issues/811#issuecomment-417053813 using your GitHub account

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