Since part 3 in this patch series updated the way we clear the "running on
compositor" flag, we can update these tests so they no longer wait for this
flag (see bug 1226118 comment 21).
This is to match the order in the header file and because in the next patch I'd
like to somewhat re-implement one method in terms of the other and having them
side-by-side will make it easier to read the code.
This patch makes no code changes whatsoever besides shifting the placement of
the function definitions within the .cpp file.
This is to align with the existing GetAnimationCollection method that takes
a frame. Also, by making this name more specific hopefully it will be used less
since we are trying to move as much code as possible over to using EffectSet
instead of AnimationCollection.
The existing code contains a comment about needing to add transitions before
animations. However, this is unnecessary since the interaction between
transitions and animations is handled by the mWinsInCascade member that is
checked in AddAnimationsForProperty.
This added method should behave in an equivalent manner to the existing
CommonAnimationManager::GetAnimationsForCompositor except for the following
differences:
* It uses the EffectSet attached to a target element rather than one of the
AnimationCollection object on the owning element.
* It returns an array of Animation objects consisting of only those Animations
that actually have the specified property as opposed to the
AnimationCollection consisting of *all* CSS animations or *all* CSS
transitions for the element regardless of whether they run on the compositor
or not.
It may not be obvious why these two methods otherwise behave in an equivalent
fashion so the following explains how the existing code is mirrored in the new
method.
The existing code is as follows:
> AnimationCollection*
> CommonAnimationManager::GetAnimationsForCompositor(const nsIFrame* aFrame,
> nsCSSProperty aProperty)
> {
> AnimationCollection* collection = GetAnimationCollection(aFrame);
> if (!collection ||
> !collection->HasCurrentAnimationOfProperty(aProperty) ||
> !collection->CanPerformOnCompositorThread(aFrame)) {
> return nullptr;
> }
>
> // This animation can be done on the compositor.
> return collection;
> }
The new EffectCompositor::GetAnimationsForCompositor begins with two checks
performed at the beginning of CanPerformOnCompositorThread: the checks for
whether async animations are enabled or not and whether the frame has refused
async animations since these are cheap and it makes sense to check them first.
The next part of EffectCompositor::GetAnimationsForCompositor checks if there is
an EffectSet associated with the frame. This is equivalent to the check whether
|collection| is null or not above.
Following, we iterate through the effects in the EffectSet.
We first check if each effect is playing or not. In the above code,
HasCurrentAnimationOfProperty only checks if the effect is *current* or not.
However, CanPerformOnCompositorThread will only return true if it finds an
animation that can run on the compositor that is *playing*. Since playing is
a strict subset of current we only need to perform the more restrictive test.
Next we check if the effect should block running other animations on the
compositor. This is equivalent to the remainder of CanPerformOnCompositorThread.
Note that the order is important here. Only playing animations should block
other animations from running on the compositor. Furthermore, this needs to
happen before the following step since animations of property other than
|aProperty| can still block animations from running on the compositor.
Finally, we check if the effect has an animation of |aProperty|. This is
equivalent to the remainder of HasCurrentAnimationOfProperty.
If all these checks succeed, we add the effect's animation to the result to
return.
KeyframeEffectReadOnly::CanAnimatePropertyOnCompositor has a comment that says
it, "Returns true |aProperty| can be run on compositor for |aFrame|" but it
does nothing of the sort.
What it *does* do is check answer the question, "If there happened to be an
animation of |aProperty| on |aFrame|, should we still run animations on the
compositor for this element?".
This patch renames the method accordingly and moves the step where we iterate
over a given effect's animated properties from
AnimationCollection::CanPerformOnCompositor to inside this method, making this
method a class method rather than a static method at the same time.
As noted in the expanded comment, the approach of blocking opacity animations
in these situations seems unnecessary but for now this patch just preserves the
existing behavior.
This patch also moves AnimationUtils out of the dom namespace since it seems
unnecessary. We typically only put actual DOM interfaces in the dom namespace.
This changes nsDisplayImage::GetDestRect and nsImageFrame::PredictedDestRect to return
the true dest rect of the image, without intersecting it with the image content box.
The only caller of these functions that actually requires a rectangle that's within
the image's content bounds is nsDisplayImage::GetOpaqueRegion, so I'm changing that
to intersect with the display item's bounds.
I'm pretty sure nsImageFrame::MaybeDecodeForPredictedSize() also prefers the unclipped
dest rect, because it cares about the scale at which the image is painted, and not
about which parts of the image are painted.
--HG--
extra : commitid : CDJJnfN7vF3
extra : rebase_source : 5b59f81ab60290f508b83db7e942559da621cb70
We need to let ContentParent and PluginModuleParent get a reference to the ProfileGatherer
during the window of time that we're profiling so that if they start to die (the actor is
starting to go away), they have a gatherer they can send their last profile data to.
--HG--
extra : commitid : LkcpDsiXmp0
extra : rebase_source : d1c9e6e7640ff759cef25920e2bc17c0484544bd
