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.
This is the main patch for the bug; it makes us use the mechanism added
in bug 1125455 to avoid sending animations that aren't currently
applying to the compositor.
Patch 7 is needed to make this code rerun in all the cases where we need
to rerun it, though.
This does somewhat less work than PostRestyleForAnimation, although I
believe PostRestyleForAnimation would be a sufficient alternative.
This is used in patch 6.
The distinction between moz_malloc/moz_free and malloc/free is not
interesting. We are inconsistent in our use of one or the other, and
I wouldn't be surprised if we are mixing them anyways.
