[css-animationworklet] Data on performance impact of syncing state for stateful animators across threads

[majido]

From @majido on August 29, 2017 19:13

(Note: Issue was created based on feedback from Houdini Paris F2F - irc logs)

There are a few cases where the current spec requires data to be send across thread and process boundaries:

1. When an animator is migrated across threads, its state should be serialized/sent/deserialized.
2. When scrolling happens on a separate thread/process, UA needs to sync scroll state to the animation thread and also the animation thread output to main thread.

There were some concern raised on performance/complexity impact of these cases. We should try to actually quantify such impact to better guide the working group.

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

[majido]

Here is the relevant discussion from IRC log:

Rossen: For our impl it looks like this'll be tricky... Marshalling state back and forth.
Rossen: We make some decisions about when to offload to compositor vs main thread based on different pressures, and now we have to sync the worklets and marshall state, and it's yet another load of complexity to handle.
Rossen: Not impossible, but certainly tricky.
Rossen: Things scaring me at face value are the sync of worklets state between threads (or processes).
franremy: We don't yet have Web Anim in Edge. Since that's a prereq for this, ther'es some work to do before we can even think about this.
Rossen: So next state...
flackr: We experimentally implement! And I"d love to see more detail on the sync issues. Ther'es very little data being synced right now.
iank_: We have the bare bones of an implementation at the moment. It's a separate thread at the moment. Not much to sync.
flackr: Just a few float values.