This patch (finally) puts pausing animations in the pending player map so that
they are resolved asynchronously.
Since this changes the pausing behavior this patch updates a number of tests so
that they continue to pass.
When a pending pause operation is interrupted by a play operation we should
preserve the original start time of the animation so that it appears to continue
moving uninterrupted. At the same time, however, for consistency with other
calls to play(), the operation should complete asynchronously.
This patch adds the method that is called when an asynchronous pause operation
has completed. It is not used yet, however, since we don't yet put
AnimationPlayer objects in the pause-pending map.
This patch adds an options flag to GetAnimationsForCompositor for two reasons.
a) We want to reuse this functionality in nsLayoutUtils.cpp rather than
duplicating the same logic. To do that and maintain the existing behavior,
however, we need to *not* update the active layer tracker when calling this
from nsLayoutUtils.cpp.
b) It's surprising that GetAnimationsForCompositor also has this side effect of
updating the active layer tracker. Adding this as an option makes it clear at
the call site that this is what will happen.
This independently would have fixed some of the problems fixed in this
bug. It would not have fixed them fully, though, since it would not
have prevented us from sending animations being covered up by !important
rules to the compositor.
This patch (after stepping through the call graph) affects the following
places:
* CommonAnimationManager::GetAnimationsForCompositor, which is used
only by nsDisplayListBuilder::AddAnimationsAndTransitionsToLayer,
which already checks the individual animations (so really no change)
* AnimationPlayerCollection::CanThrottleAnimation
* ActiveLayerTracker::IsStyleAnimated
* nsLayoutUtils::HasAnimationsForCompositor
* nsLayoutUtils::HasAnimations (which is used only to check whether we
can make the 0-opacity optimization)
I believe it makes sense to change all of these locations (although in
the long term we want to throttle (or similar) more animations).
Without this patch, I believe we're forcing the creation of an opacity
layer because we think we have animations to send to it.
This saves some extra work that we don't need to do.
Mechanically, the patch moves a chunk of code that is around the last
part of the function and converts it to an early return that's slightly
earlier than that last part, thus also including the skipping of the
throttling checks in what we skip for the early return.
I want to do this here since patch 9 introduces a new call to
EnsureStyleRuleFor.
I don't have a test case that requires this, but it seems like a good
idea. (It was an incorrect theory for fixing a test failure that I was
debugging, but still seems worth doing.)
This avoids some extra work that was added in bug 1125455 now that we
have a mechanism for detecting when animations start and stop being in
effect (introduced in patch 7).
This is also needed to prevent infinite recursion in patch 9.
