[css-animationworklet] Pass additional timelines as part of additional options and only have a single timeline in constructor.

[majido]

From @flackr on July 20, 2017 19:31

I think WorkletAnimation would be more consistent with Web Animations if we just passed the primary timeline in the constructor and moved additional timelines to the additional options bag.

i.e.

new WorkletAnimation('foo', [new KeyframeEffect(...)], scrollTimeline, {'documentTime': document.timeline});

Then we could allow attaching to / detaching from additional timelines within the object. For example:

registerAnimator('twitter-header', class {
  constructor(options) {
    this.options_ = options;
  }

  animate(timeline, effect) {
    ...
    if (condition) {
      this.options_.documentTime.attach(this);
      // Or this.attach(this.options_.documentTime);
      // At this point in time the animation will now tick with the DocumentTimeline as well
      // as the ScrollTimeline.
    } else if (other_condition) {
      // detach from document timeline.
    }
  }
});

It's also possible that since there is a single DocumentTimeline it may be available on the global scope to attach to / detach from.

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

[majido]

There is two part this proposal:

1. Make one timeline a primary timeline.
2. Allow animation to explicitly attach/detach to timelines.

I support both these ideas but let me add more color to the discussion.

A Primary Timeline

The main benefit here is that it will make integration with Web Animation much simpler. For example it is now clear what is the time value that will be used in the animation events i.e., event timeline time.

Explicit Timeline Attach/Detach

Our previous design was passing multiple timelines to the animation. An issue with that design is that the animation needed to be updated anytime any of its timelines has changed. However, this is inefficient in many common usecases. Take for example the “hidy bar” effect where the animation initially tracks the scroll offset (via ScrollTimeline) but as soon as the finger is lifted it continues the animated effect by tracking time (via DocumentTimeline). So in the first phase the animation needs to only be responsive to scroll offset changes and in seconds phase it needs to be responsive to both scroll offset and time. So in this case, if we had both timelines at the beginning then we would need to call animate function every frame even if there was no scrolling in that frame!

The explicit attach/detach idea help solve this issue. In particular, the animation will get all its needed timelines (primary, and those in options bag) during its construction. Then it can attach/detach to them as needed and its update rate is determined by its attached timelines.

So here is the proposal in more concrete terms:

• Attaching an animation to a timeline means that it will be updated if the timeline currentTime value changes
• WorkletAnimation can explicitly attach itself to any timeline it has a reference to.
• On initialization, a WorkletAnimation is attached to its primary timeline but not attached to other timeline that it received via its options bag.
• The animation may still read the currentTime value of its detached timelines.

[majido]

From @birtles on July 26, 2017 2:0

A few bits of feedback:

• I feel a little bit uneasy about the primary timeline idea, because:
  • Blessing one particular timeline feels a little odd. Is there somewhere else in the platform where we have this concept (so we can at least align terminology etc.)?
  • It seems odd that you pass different classes of timelines using very different means (regular argument vs property bag).
  • Can you change your primary timeline over time? e.g. if your hidey bar animation goes past the scroll threshold and becomes a timed animation, semantically it feels like your primary timeline has changed. If you can change the primary timeline, then using such different means to pass the different types of timelines seems all the more odd.
• I suspect we might find some good ideas in WPF and event .NET since they deal with hierarchies of timelines, I believe.
• The idea of attaching/detaching makes sense though. (We might call it listening?)