Bug 1230110 - HTMLImageElement should call its superclass's DestroyContent(). r=smaug

Bug 1230118 - added asserts on aOwner and aOwner->Elm() r=surkov

Backed out 2 changesets (bug 1221992) for windows debug assertions in browser_perf-categories-js-calltree.js Backed out changeset bcd90e591038 (bug 1221992) Backed out changeset 6affaa386b9b (bug 1221992)

Bug 1228711 - Cubemap images must be square. - r=benwa

Backed out 2 changesets (bug 1230118, bug 1230110) for windows debug assertions in browser_perf-categories-js-calltree.js Backed out changeset a9ce85f77af9 (bug 1230118) Backed out changeset b9d8d05aa4ee (bug 1230110)

Bug 1226118 part 15 - Remove no-longer-necessary delays from test_running_on_compositor.html; r=hiro 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).

Bug 1226118 part 14 - Rewrite GetAnimationCollection(nsIFrame*) in terms of the existing GetAnimationCollection; r=dholbert This simply allows us to share the code that maps from pseudo-types to atoms.

Bug 1226118 part 13 - Move the GetAnimationCollection definitions side-by-side; r=dholbert 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.

Bug 1226118 part 12b - Rename CommonAnimationManager::GetAnimations to GetAnimationCollection; r=dholbert 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.

Bug 1226118 part 12a - Make RestyleManager::GetMaxAnimationGenerationForFrame used frame-based GetAnimationCollection; r=dholbert

Bug 1226118 part 11 - Remove CommonAnimationManager::GetAnimationsForCompositor; r=dholbert

Bug 1226118 part 10 - Use EffectCompositor::GetAnimationsForCompositor in nsLayoutUtils; r=dholbert

Bug 1226118 part 9 - Use EffectCompositor::GetAnimationsForCompositor in nsDisplayList; r=dholbert 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.

Bug 1226118 part 8 - Add EffectCompositor::GetAnimationsForCompositor that uses the EffectSet rather than AnimationCollection; r=dholbert 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.

Bug 1226118 part 7 - Rename and rework KeyframeEffectReadOnly::CanAnimatePropertyOnCompositor to ShouldBlockCompositorAnimations; r=hiro 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.

Bug 1226118 part 6 - Remove no longer used LayerAnimationRecord/Info code from AnimationCommon; r=dholbert This code has now been moved to LayerAnimationInfo.{h,cpp} and is not used in AnimationCommon.

Bug 1226118 part 5 - Move LogAsyncAnimationFailure to AnimationUtils; r=dholbert 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.

Bug 1226118 part 4 - Use EffectSet in ActiveLayerManager's animated-scale checks; r=dholbert

Bug 1226118 part 3 - Use EffectSet in CommonAnimationManager::ClearIsRunningOnCompositor; r=hiro, r=dholbert

Bug 1226118 part 2 - Use EffectSet in nsLayoutUtils animation functions; r=dholbert