Bug 1078122 part 6 - Store the previous finished state; r=dholbert
commit63eb4db9c0d920136ce1413dc23c36d8a19aa839
authorBrian Birtles <birtles@gmail.com>
Mon, 20 Oct 2014 04:55:47 +0000 (20 13:55 +0900)
committerBrian Birtles <birtles@gmail.com>
Mon, 20 Oct 2014 04:55:47 +0000 (20 13:55 +0900)
treeb73ea73b86a0ac640910ec4a9eff968dfdf1f475
parentc1d26b86ba66df8992a60ac8ca55f174aa8209b9
Bug 1078122 part 6 - Store the previous finished state; r=dholbert

AnimationPlayer::CanThrottle determines if an animation player has just finished
by inspecting the value of mLastNotification. This is problematic for two
reasons:

1. mLastNotification is intended to be used for events (as the XXX comment
   notes)
2. mLastNotification is specific to CSS Animations and should be moved to
   CSSAnimationPlayer.

To address this, this patch adds an extra member mIsPreviousStateFinished. The
Web Animations spec already defines animation players as having such a member:

  http://w3c.github.io/web-animations/#previous-finished-state

We set it to true when we calculate the style for an animation that has
finished. This differs slightly from the code it is replacing as explained
below.

In the case of CSS Animations we perform the following sequence of steps on each
sample.

  1. EnsureStyleRuleFor (calls CanThrottle, and maybe ComposeStyle)
  2. GetEventsForCurrentTime

In the existing code, we update mLastNotification in (2) which happens on every
sample, even throttled samples.

In this patch, however, we update mIsPreviousStateFinished in (1) during the
ComposeStyle step which only happens for unthrottled samples. So, as of this
patch, in CanThrottle, we ask "have we newly entered the finished state since
the last *unthrottled* sample?", whereas previously we simply looked for
a change since the last sample, throttled or not. However, if the answer to the
question is "yes", then we'll run an unthrottled sample and update
mIsPreviousStateFinished so these should be functionally equivalent.

Another subtle difference is that this patch looks at the player's finished
state rather than the animation phase of its source content, and these will
produce different results in the case where the player is paused. However, since
paused animations are not run on the compositor, this should not matter.

In the case of CSS Transitions, AnimationPlayer::CanThrottle() is not currently
used and so mIsPreviousStateFinished is irrelevant.

Ultimately, both the existing and the new code is somewhat fragile but hopefully
this will be addressed by:
* Replacing mIsPreviousStateFinished with inspecting whether the finished
  promise is settled (bug 1074630),
* Merging more of the code in nsAnimationManager and nsTransitionManager and
  applying a unified approach to sampling that better accommodates these
  considerations.
dom/animation/AnimationPlayer.cpp
dom/animation/AnimationPlayer.h