-
Notifications
You must be signed in to change notification settings - Fork 35
API for communicating state between frames #4
Comments
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? |
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:
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. |
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 Closing this issue. |
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
.The text was updated successfully, but these errors were encountered: