Commit Graph

139 Commits

Author SHA1 Message Date
L. David Baron
824c76c900 Bug 960465 patch 14 - Retain finished transitions until the next style change or until removed from transition-property. r=birtles
Note that this increases memory use for completed transitions since we
don't throw away the data when the transitions complete.  That said,
this matches what we do for CSS Animations, and it's needed (once we
switch to the new rules for starting transitions) to maintain the
invariant that unrelated style changes don't trigger transitions.

The storage issues could be optimized in the future if it turns out to
be a problem, but I think that's unlikely, given that we'll never store
more than one for any element+property combination.
2015-02-17 11:15:04 +13:00
Nicholas Nethercote
242708cf72 Bug 1127201 (attempt 2, part 1) - Replace most NS_ABORT_IF_FALSE calls with MOZ_ASSERT. r=Waldo.
--HG--
extra : rebase_source : 488e401ff87e31a2074c4108c4df0572d9536667
2015-02-09 14:34:50 -08:00
Andrew McCreight
d3826daa16 Back out Bug 1127201 (part 2) for various problems. 2015-02-06 15:04:32 -08:00
Nicholas Nethercote
d34f0301b8 Bug 1127201 (part 2) - Convert all NS_ABORT_IF_FALSE calls to MOZ_ASSERT. r=Waldo.
--HG--
extra : rebase_source : 99182e70335d2b5ff95f8c528ae992d37294be3a
2015-02-04 20:05:36 -08:00
Brian Birtles
8162708cc1 Bug 1123196 part 1 - While player is waiting to start, return its pending start time; r=jwatt
After starting layer animations we set the same start time on content
animations but we don't apply it until the next tick (see bug 1112480 for
background). However, in some circumstances, we can end up creating layer
animations again within the same refresh driver tick. In this case, we should
initialize the animations with the same start time as we previously used.

This patch exposes the pending start time set on content animations so that,
if set, we can use it when building layer animations.
2015-02-03 14:08:37 +09:00
Jonathan Watt
393081114a Bug 1105098 - Make AnimationTimeline always return the same parent object (even after document.open()) and replace the document's timeline if the document is reset. r=smaug,birtles 2015-01-26 17:08:51 +00:00
Mason Chang
6c10033ff7 Bug 1119981. Disable test_deferred_start.html on b2g for race condition in test. r=bbirtles 2015-01-16 09:33:49 -08:00
Brian Birtles
483f9be18f Bug 1112480 part 10 - Mark css-animations/test_animation-pausing.html and css-transitions/test_animation-pausing.html as no longer failing; r=jwatt
With this updated approach to starting pending animations, these tests should no
longer fail on Mac 10.8 or Windows.
2015-01-09 07:57:59 +09:00
Brian Birtles
816dbf54ef Bug 1112480 part 9 - Remove call to PostUpdate from AnimationPlayer::ResumeAt; r=jwatt
Since pending animations are no longer started outside of a style update, we no
longer need to call PostUpdate from ResumeAt.
2015-01-09 07:57:58 +09:00
Brian Birtles
a31477d9b4 Bug 1112480 part 8 - Remove AnimationTimeline::FastForward; r=jwatt
Now that we don't actually start pending animations until the following refresh
driver tick we no longer need to be able to fast-forward the AnimationTimeline
between ticks.
2015-01-09 07:57:58 +09:00
Brian Birtles
7a9094aa6e Bug 1112480 part 7 - Add checking for orphaned players; r=jwatt
When a player is made pending, we rely on it being added to a pending player
tracker that will eventually start the player. However, there are a few
situations where this might not happen. For example, we can't find a pending
player tracker (e.g. there's no source content or the source content isn't
attached to a document), or the pending player tracker disappeared.

In these cases we still want to ensure that such a player does actually get
started. This patch attempts to detect such situations and start players
accordingly.

There are, unfortunately, currently no tests for this. I have been unsuccessful
in recreating any of the situations these tests are supposed to cover.
2015-01-09 07:57:58 +09:00
Brian Birtles
ac47cd0a02 Bug 1112480 part 6 - Make PendingPlayerTracker call StartOnNextTick; r=jwatt
This patch switches on the new, "actually start the player in the next refresh
driver tick" behavior. It updates PendingPlayerTracker, adding
a StartPendingPlayersOnNextTick method which calls the appropriate method on
AnimationPlayer. The existing StartPendingPlayers is renamed to
StartPendingPlayersNow and is used for testing only.

Furthermore, since we now expect AnimationPlayer::StartOnNextTick to be
functional, AnimationPlayer::DoPlay is updated to use it when there is no
document available. This should make playing an animation player always
asynchronous, that is, always transition to the pending state temporarily
(unless we are already playing).
2015-01-09 07:57:58 +09:00
Brian Birtles
9eb65d26c7 Bug 1112480 part 5 - Add AnimationTimeline::IsUnderTestControl; r=jwatt
Earlier in this patch series we added AnimationPlayer::StartOnNextTick which
takes a ready time parameter expressed in timeline time. In order to call this
method when painting finishes we need to convert the TimeStamp recorded when
painting finished to a timeline time. However, when the timeline is driven by
a refresh driver under test control we can no longer meaningfully do this
conversion since there is no correspondence between the notion of time used to
record the time when painting finished (wallclock time) and the notion of time
used by the timeline (which has been arbitrarily adjusted by test code).

We need a way to detect this situation so that we know not to call
ToTimelineTime in that case.

Alternatively, we could make ToTimelineTime automatically return a null value
when its refresh driver is under test control. However, in this situation
ToTimelineTime can still actually be used to convert a TimeStamp to a timeline
time as long as the TimeStamp is from the same refresh driver. Indeed,
GetCurrentTime does exactly that. So if we were to go down that route we would
have to provide a way for GetCurrentTime to work around that restriction.

For now, this patch puts the onus on the caller of ToTimelineTime to check if
the timeline is under test control first (unless they are passing a TimeStamp
from the same refresh driver, in which case there is no need to check).
2015-01-09 07:57:58 +09:00
Brian Birtles
f13b2102bb Bug 1112480 part 4 - Use mPendingReadyTime in AnimationPlayer::Tick; r=jwatt
This patch makes AnimationPlayer act on requests to StartOnNextTick by checking
for mPendingReadyTime on each tick.

We also check that the ready time is not in the future since currently it might
be possible that we get multiple calls to AnimationPlayer::Tick within a single
refresh driver tick.

Note that this patch shouldn't actually produce any observable change yet,
however, since we don't call StartOnNextTick anywhere.
2015-01-09 07:57:58 +09:00
Brian Birtles
8fbf68a16a Bug 1112480 part 3 - Add AnimationPlayer::StartOnNextTick; r=jwatt
Adds a method that schedules an animation player to begin on the next tick using
the supplied time as the start time.

We don't call this yet, however, but simply add the method and the
mPendingReadyTime member it sets.
2015-01-09 07:57:58 +09:00
Brian Birtles
cc7ea10335 Bug 1112480 part 2 - Factor out ResumeAt; r=jwatt
In addition to AnimationPlayer::StartNow, this patch series also makes
AnimationPlayer::Tick start animations.

Since these methods will share a lot of code we first factor out a common
ResumeAt method to encapsulate the common code.
2015-01-09 07:57:58 +09:00
Brian Birtles
c6ebd438ae Bug 1112480 part 1 - Adjust tests to accommodate changed animation start behavior; r=jwatt
In this patch series we adjust the behavior of animation starting so that the
animation does not actually start until the following refresh driver tick. This
requires some tweaks to tests to ensure they continue to pass.
2015-01-09 07:57:58 +09:00
Brian Birtles
63f5d21f88 Bug 1117955 - Disable css-transitions/test_animation-pausing.html on Windows 2015-01-07 15:00:26 +09:00
Brian Birtles
579783f725 Bug 1117955 - Disable css-animations/test_animation-pausing.html on Windows 2015-01-06 14:36:55 +09:00
Brian Birtles
fd8aff9c0e Bug 1113413 - Make refresh driver go back immediately when restored from test control; r=vlad 2015-01-06 10:56:02 +09:00
Brian Birtles
62ee098b80 Bug 927349 part 30 - Cancel transitions when we have a change to a non-animatable style; r=heycam 2015-01-06 10:55:59 +09:00
Brian Birtles
ddaaa69a98 Bug 927349 part 29 - Temporarily disable failing tests {browser_555547.js on Windows opt, test_animation-pausing.html on 10.8, test_deferred_start.html on mulet}; r=me (as discussed with jwatt) 2014-12-24 15:42:37 +09:00
Brian Birtles
291701ad1b Bug 927349 part 26 - Add a test for compositor animations with a delay; r=nical
This patch adds a test that we correctly incorporate the delay when setting
a layer animation's initialCurrentTime.

The notion of 'current time' on layer animations differs from that on main
thread animations in that it does not incorporate the animation delay.
Instead, we wait until an animation's delay has complete before putting it
on the layer and then it we add without delay.

For animations that are still waiting to start we need to factor this delay into
the initialCurrentTime stored on the layer animation so that when we update
the animation's start time it represents the time *after* the delay has
finished. Previously we failed to do this but no tests failed since all existing
tests for delay rely on DOMWindowUtils.advanceTimeAndRefresh which avoids this
particular code path (since we don't add pending animations to layers while
the refresh driver is under test control).

This patch adds a test for animation delay that does not rely on
DOMWindowUtils.advanceTimeAndRefresh which has been confirmed to fail if we
don't incorporate the delay in our calculation of initialCurrentTime.
2014-12-25 16:28:25 +09:00
Brian Birtles
54a9341689 Bug 927349 part 25 - Test cancelling of players; r=heycam 2014-12-25 16:28:24 +09:00
Brian Birtles
06faed4dae Bug 927349 part 24 - Add a test that empty animations still start; r=heycam 2014-12-25 16:28:24 +09:00
Brian Birtles
01a5445ce7 Bug 927349 part 23 - Wait on player.ready on test_running_on_compositor.html; r=jwatt 2014-12-25 16:28:24 +09:00
Brian Birtles
c4aa216c4c Bug 927349 part 22 - Make AnimationPlayer wait for animations to be rendered before starting; r=jwatt
This patch (finally!) introduces the delayed start behavior. It updates
AnimationPlayer::DoPlay to put animations in the PendingPlayerTracker from
where they are triggered.

This patch also updates nsTransitionManager to set the animation's source
before calling Play as otherwise the AnimationPlayer won't be able to access
the pending player tracker (which it locates by navigating AnimationPlayer ->
Animation (source content) -> target element -> composed doc -> pending player
tracker). In future, when we support setting the AnimationPlayer.source property
we will make this more robust so that the order in which these steps are
performed doesn't matter.

This patch also updates a couple of tests to reflect the fact that
AnimationPlayer will now return the pending state.
2014-12-25 16:28:24 +09:00
Brian Birtles
e5b88e8ef0 Back out parts 22-29 from bug 927349 for causing intermittent test failure in css-animations/test_animation-pausing.html on 10.8 2014-12-26 11:54:43 +09:00
Brian Birtles
8f3f4c1376 Bug 927349 part 29 - Disable failing browser_555547.js on Windows opt - pushed again without backing out parts 22-29 at the same time; r=me
In https://hg.mozilla.org/integration/mozilla-inbound/rev/3ab2ff9b9f94
I accidentally pushed part 29 along with a backout for parts 22-29. This patch
reverts that change.

If this changset causes problems, the following changesets should be backed out:

https://hg.mozilla.org/integration/mozilla-inbound/rev/477f46897b0b
https://hg.mozilla.org/integration/mozilla-inbound/rev/6c345954bce5
https://hg.mozilla.org/integration/mozilla-inbound/rev/642e400b22a9
https://hg.mozilla.org/integration/mozilla-inbound/rev/9bdf7c2279fa
https://hg.mozilla.org/integration/mozilla-inbound/rev/79cac8c71159
https://hg.mozilla.org/integration/mozilla-inbound/rev/cfe757e478d5
https://hg.mozilla.org/integration/mozilla-inbound/rev/eaf834051cbd
2014-12-26 08:49:20 +09:00
Brian Birtles
414a5c831f Bug 927349 part 29 - Disable failing browser_555547.js on Windows opt; r=me (as discussed with jwatt) 2014-12-25 16:31:55 +09:00
Brian Birtles
aa18819813 Bug 927349 part 26 - Add a test for compositor animations with a delay; r=nical
This patch adds a test that we correctly incorporate the delay when setting
a layer animation's initialCurrentTime.

The notion of 'current time' on layer animations differs from that on main
thread animations in that it does not incorporate the animation delay.
Instead, we wait until an animation's delay has complete before putting it
on the layer and then it we add without delay.

For animations that are still waiting to start we need to factor this delay into
the initialCurrentTime stored on the layer animation so that when we update
the animation's start time it represents the time *after* the delay has
finished. Previously we failed to do this but no tests failed since all existing
tests for delay rely on DOMWindowUtils.advanceTimeAndRefresh which avoids this
particular code path (since we don't add pending animations to layers while
the refresh driver is under test control).

This patch adds a test for animation delay that does not rely on
DOMWindowUtils.advanceTimeAndRefresh which has been confirmed to fail if we
don't incorporate the delay in our calculation of initialCurrentTime.
2014-12-25 16:28:25 +09:00
Brian Birtles
6535f8f5a2 Bug 927349 part 25 - Test cancelling of players; r=heycam 2014-12-25 16:28:24 +09:00
Brian Birtles
ce6bc54785 Bug 927349 part 24 - Add a test that empty animations still start; r=heycam 2014-12-25 16:28:24 +09:00
Brian Birtles
30b7966bc4 Bug 927349 part 23 - Wait on player.ready on test_running_on_compositor.html; r=jwatt 2014-12-25 16:28:24 +09:00
Brian Birtles
94756a7b6f Bug 927349 part 22 - Make AnimationPlayer wait for animations to be rendered before starting; r=jwatt
This patch (finally!) introduces the delayed start behavior. It updates
AnimationPlayer::DoPlay to put animations in the PendingPlayerTracker from
where they are triggered.

This patch also updates nsTransitionManager to set the animation's source
before calling Play as otherwise the AnimationPlayer won't be able to access
the pending player tracker (which it locates by navigating AnimationPlayer ->
Animation (source content) -> target element -> composed doc -> pending player
tracker). In future, when we support setting the AnimationPlayer.source property
we will make this more robust so that the order in which these steps are
performed doesn't matter.

This patch also updates a couple of tests to reflect the fact that
AnimationPlayer will now return the pending state.
2014-12-25 16:28:24 +09:00
Brian Birtles
1df0d8114c Bug 927349 follow-up to (hopefully) fix breakage from GetCurrentTime on non-unified Windows build on a CLOSED TREE 2014-12-22 13:16:11 +09:00
Brian Birtles
9b70aa8285 Bug 927349 part 21 - Factor out AnimationPlayer::UpdateSourceContent; r=jwatt
In the future we will want to specifically just update source content without
necessarily triggering any other actions that might take place on a tick (like
queuing events).
2014-12-22 09:35:42 +09:00
Brian Birtles
24eaa57ecc Bug 927349 part 19 - Don't add pending animations to layers when their refresh driver is under test control; r=jwatt 2014-12-22 09:35:42 +09:00
Brian Birtles
79e39d6e6a Bug 927349 part 16 - Do a full reflow when we have pending animations; r=jwatt
We want to time animations from when their first frame is painted. However,
interruptible reflow complicates this since, for a given set of pending
animations, some may be painted whilst others are not. To simplify this we
simply force an uninterruptible reflow when we have animations that are
waiting to start.
2014-12-22 09:35:41 +09:00
Brian Birtles
0cea4b72d5 Bug 927349 part 15 - Schedule a paint when a new pending animation is added; r=jwatt
We would like to trigger animations from the point when the first frame of the
animation is painted. However, some animations will never trigger a paint (e.g.
animations with an empty keyframes rule). These animations should start start
however. To ensure this, whenever an animation is newly pending we schedule
a paint.
2014-12-22 09:35:41 +09:00
Brian Birtles
53d761ef44 Bug 927349 part 14 - Store reference to owning document on PendingPlayerTracker; r=jwatt
This patch adds a reference from PendingPlayerTracker back to the document
object that owns it. This is used in the next patch in this series to find the
document's root frame for scheduling a paint.
2014-12-22 09:35:41 +09:00
Brian Birtles
0dcad886e1 Bug 927349 part 9 - Add PendingPlayerTracker::StartPendingPlayers; r=jwatt 2014-12-22 09:35:41 +09:00
Brian Birtles
fb0d9d7187 Bug 927349 part 8 - Fast-forward the timeline before resolving start times; r=jwatt
Normally animation players get times from their timeline which is based on the
refresh driver for their associated document. However, for animations that
we time from when their first frame has been rendered, we want to record the
actual time when painting finished as their start time. If we wait until the
next refresh driver tick then the delay between playing an animation and its
actual start will be too great.

In this patch, we introduce a mechanism for fast-forwarding a timeline to a
time between the current refresh driver time and the next refresh driver tick.
By adjusting the timeline rather than the player we maintain a consistent state
(in fact, if we just naively set the animation player start time to the
timestamp value we recorded when painting finished it will appear to start in
the future and the animation will temporarily jump from playing, to waiting to
start, then back to playing again on the next refresh driver tick).

To be completely consistent, however, when we fast-forward the timeline we
should tell all animation players listening to the timeline to mark their
target element as needing a style flush. Otherwise we may be able to observe an
inconsistency between some animation players' current time and the computed
style of their targets.

We don't, however, currently know which players are observing a given timeline.
We will likely introduce that in the near future (in order to implement
AnimationTimeline.getAnimationPlayers) and fix the inconsistency in timing then.
A test later in the patch series verifies this inconsistency so it is easy to
fix in future.

An alternative approach would be to simply record the time when animation should
start, send that time to the compositor but don't actually update the animation
start time on the main thread until the subsequent refresh driver tick. Such
an approach is complex as it introduces an additional state--"finished pending
but not yet started". We will attempt to switch to that approach in bug 1112480.
2014-12-22 09:35:41 +09:00
Brian Birtles
7f2f1073ca Bug 927349 part 7 - Factor out AnimationTimeline::GetRefreshDriver into a separate method; r=jwatt
This is in preparation for adding AnimationTimeline::FastForward in the next
patch which will reuse this code.
2014-12-18 08:42:41 +09:00
Brian Birtles
c93cabd2c1 Bug 927349 part 6 - Rename AnimationPlayer::ResolveStartTime to AnimationPlayer::StartNow; r=jwatt
ResolveStartTime is a bit hard to understand. Eventually, once we implement
SetStartTime, we can probably remove this method altogether and just use that.
This renaming moves us closer to that direction.

This patch also adjusts a comment about the preconditions for calling StartNow.
This is because in a subsequent patch in this series we will update the
assertion at the beginning of StartNow to simply check that the player is
pending.
2014-12-18 08:42:41 +09:00
Brian Birtles
9fdafb68a4 Bug 927349 part 5 - Cancel players that are no longer used; r=jwatt
This patch adds a means of terminating an animation so that is has no effect.
The procedure is defined by Web Animations:

  http://w3c.github.io/web-animations/#cancelling-a-player-section

We don't implement all of this, however, since we don't currently support the
finished promise or custom effects.

In a later bug we will expose this as the cancel() method on AnimationPlayer.

We call this method for terminated animations in nsAnimationManager and
nsTransitionManager to ensure they get removed from the pending player tracker
and so that, for example, the ready promise of CSS Animation player objects is
rejected when the corresponding item is removed from animation-name.
2014-12-18 08:42:41 +09:00
Brian Birtles
c91b2dea43 Bug 927349 part 4 - Make the ready Promise be created lazily; r=heycam
In Bug 1104435 we made the initial ready promise be created lazily. This patch
takes this a step further and makes sure we don't create the promise at all
unless it is explicitly requested.
2014-12-18 08:42:41 +09:00
Brian Birtles
e7e0331a96 Bug 927349 part 3 - Cancel a pending play when pause is called; r=jwatt
This patch updates the pause procedure for AnimationPlayer so that if there is
a pending play it will be cancelled.

At the same it removes the existing check for a redundant call to Pause when we
are already paused. This check is not necessary since if we are already paused
the method will have no effect anyway.

Finally, this patch updates the comment about going to the pending state while
pausing since this will happen in bug 1109390.
2014-12-18 08:42:41 +09:00
Brian Birtles
97da0a29b5 Bug 927349 part 2 - Add AnimationPlayer::mIsPending and return "pending" from AnimationPlayer::PlayState(); r=jwatt
This patch adds a member for tracking if a player is currently pending or not
and uses this to return the "pending" state from PlayState(). We don't currently
set mIsPending to true yet, however.

Additionally, this patch updates AnimationPlayer::ComposeStyle to set
aNeedsRefreshes to true when the player is pending. This is used by the
appropriate animation/transition manager to determine if it should continue to
observe the refresh driver or not.
2014-12-18 08:42:41 +09:00
Brian Birtles
1c721ff76d Bug 927349 part 1 - Add PendingPlayerTracker; r=jwatt
This patch adds a hashtable to nsDocument that stores all the animation players
that are currently waiting to start. In the future it may also be used to store
players that are waiting to pause which is why the methods are called
AddPlayPending/RemovePlayPending instead of just AddPlayer/RemovePlayer.
2014-12-18 08:42:41 +09:00