- From: Brian Birtles <bbirtles@mozilla.com>
- Date: Mon, 28 Apr 2014 09:03:35 +0900
- To: "public-fx@w3.org" <public-fx@w3.org>
Hi, In Web Animations we have AnimationPlayer objects that do playback control. They're the link between an AnimationTimeline and its animation content and they take care of seeking, playing backwards, pausing etc. They have properties like - startTime - currentTime - paused - playbackRate etc. They also serve one additional role: when two animations are targetting the same element, they tell us which one wins (or, when using additive animation, which one adds to which for non-commutative animation like transforms). For CSS this normally doesn't matter since CSS has its own rules for prioritization but for animations made with script the basic rule is that the animation that starts later, clobbers the one that starts before it. That holds even if you pause one or the other. There are some subtleties to it but that's basically it. In other words, an AnimationPlayer's start time has significance for working out the priority of animations. The question is, how should all these times change when you pause/seek? We have two models so far: a) The time lag model * startTime - doesn't change (unless you deliberately set it) * timeLag - a new property that represents the amount an animation is lagging behind where its startTime / AnimationTimeline say it should be up to, due to actions like pausing / seeking etc. So, if you pause an animation for 2s, the timeLag will increase by 2000 but the startTime won't change. If you seek forwards 1s, the timeLag will decrease be 1000 but again, the startTime won't change. When you're paused the timeLag continually accumulates. b) The adjusted start time model * startTime - changes when you pause So, if you pause an animation for 2s, its startTime increases by 2000. If you seek forwards 1s, its startTime decreases by 1000. *However*, because we use the start time for prioritizing animations and because that priority shouldn't change due to pausing etc., we also need to maintain the *original* start time for prioritizing purposes. What's more, in order for script to be able to have fine control of prioritization it seems desirable for animations to be able to set startTime (as they can in (a)) which would suggest setting the property influences the *original* start time. We introduced (b) because it seems simpler than (a) but it has two caveats: 1. Less information about prioritization is exposed. 2. If getting startTime reports the adjusted startTime but setting it also updates the original startTime, we arrive at a situation where setting the property to its same value would have side effects. From the above I suspect (a) is better. timeLag is calculable from the other parameters so we could hide it too. Are there other arrangements that make more sense? Best regards, Brian
Received on Monday, 28 April 2014 00:04:05 UTC