New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pass additional timelines as part of additional options and only have a single timeline in constructor. #61

Open
flackr opened this Issue Jul 20, 2017 · 2 comments

Comments

Projects
None yet
3 participants
@flackr
Contributor

flackr commented Jul 20, 2017

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.

@majido

This comment has been minimized.

Show comment
Hide comment
@majido

majido Jul 20, 2017

Member

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.
Member

majido commented Jul 20, 2017

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.
@birtles

This comment has been minimized.

Show comment
Hide comment
@birtles

birtles Jul 26, 2017

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?)

birtles commented Jul 26, 2017

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?)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment