Skip to content
This repository has been archived by the owner on Apr 20, 2019. It is now read-only.

API for communicating state between frames #4

Closed
RByers opened this issue Sep 22, 2016 · 3 comments
Closed

API for communicating state between frames #4

RByers opened this issue Sep 22, 2016 · 3 comments

Comments

@RByers
Copy link
Member

RByers commented Sep 22, 2016

Some effects rely on communicating state from one frame to the next (eg. a physics-based animation which tracks current momentum of different elements). Worklets don't permit state to be stored on the global object (see w3c/css-houdini-drafts#308). We should define an explicit API for passing state from one animate invocation and the next for a given Animator.

For example, the spring-timing demo stores properties directly onto the AnimationProxy.

@RByers RByers changed the title Design the API for communicating state between frames API for communicating state between frames Sep 22, 2016
@appsforartists
Copy link
Contributor

The examples in the README represent the Animator as an anonymous class. Wouldn't you then store state that persists across frames in that instance?

@majido
Copy link
Member

majido commented Sep 27, 2016

WorkletGlobalScope is designed to be created and destroyed at anytime and it requires registered class to be idempotent. So keeping any state on the instance is actually not a workable solution.

We have talked about a few options here:

  1. Keep state on custom CSS properties that get synced back to document scope. This works for element related state but it is a bit clunky for global state
  2. Pass in an state to animate. This object will be structured cloned and copied to the new scope if the current worklet scope is destroyed.
  3. Same as above but make it an attribute on animator instance e.g., animator.state.

I think there is an interest to solve this issue for other houdini APIs e.g., Layout so we should look for a solution that works there too.

@majido
Copy link
Member

majido commented Apr 7, 2018

We now allow the animations to keep state on the animation instance. Current specification guarantees that state to be reliable during the lifetime of the animation.

It does so but defining a set of callback which enables the animation to serialize and deserialize its state if we ever need to migrate it. We are now considering the possibility to replace such callback
with an explicit state property on the animation instance in issue #87.

Closing this issue.

@majido majido closed this as completed Apr 7, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants