This changes the behavior of the CanPerformOnCompositorThread methods of
both ElementAnimations and ElementTransitions to check that the
respective animations or transitions are actually running. This is ok
because:
- The main caller is nsLayoutUtils::HasAnimationsForCompositor, and all
of its callers pretty clearly want the more restricted behavior (they're
concerned with layer activity)
- The only other callers of these functions are
nsAnimationManager::FlushAnimations and
nsTransitionManager::FlushTransitions (determining when to do
throttling), nsAnimationManager::GetAnimationsForCompositor (whose
only caller,
nsDisplayListBuilder::AddAnimationsAndTransitionsToLayer, also checks
IsRunningAt). I think these also all want or are fine with having
the IsRunningAt check.
As to the actual changes:
- In the animation manager, I think it's a mistake that
ElementAnimation::IsRunningAt didn't already check
mIterationDuration, since we throw out animations with a bad
iteration-duration in ElementAnimations::EnsureStyleRuleFor. So this
makes that change as well.
- In the transition manager, IsRunningAt already checks
!IsRemovedSentinel().
I've confirmed in gdb on a device that this fixes the repeated
nsIFrame::SchedulePaint calls that were the symptom of this bug.
I believe this patch also makes it so that a short animation of a
property that can't be animated on the compositor doesn't prevent the
entire duration of the animation of a property that can from being
throttled (having the main thread style updates suppressed).
I've been wanting to remove this code for a while. I think this code is
problematic for three reasons:
(1) It's in the middle of code where it doesn't belong, and which ought
to be handling purely-style-system things. (This is blocking me
from reusing that code elsewhere, e.g., in bug 977991 and
bug 960465, both of which could use it in some form.)
(2) It defeats the optimization from bug 790505 whenever we do a
miniflush (in other words, whenever we have any style change,
whether or not it's related)
(3) It means the conditions for when we decide to ship a new set of
animation data to a layer doesn't cover all the cases the layer
needs it. In particular, we only run this miniflush code when we
have a currently running animation or transition that's running on
the compositor thread. On the other hand, the UpdateTransformLayer
style change handling in DoApplyRenderingChangeToTree depends on
whether the frame currently has a transform layer, which can
continue to be true for a bit after the animation stops. So if we
need to send animations to the layer because of a transform style
change that happens soon after an animation completes, our style
change handling will find the existing layer and call its
SetBaseTransformForNextTransaction method but never do anything
that triggers layer construction. The style throttling code, in
turn, will never stop doing main thread updates because the
animation generation on the layer is out-of-date, and these main
thread updates will keep the layer active, but they'll never show
up because the stale animation data overrides the new transform
that we've been setting. (At least, I think that's what was
happening; it makes sense to me and matches the behavior I was
observing. I didn't verify which main thread updates and which
layer updates were actually happening, though.)
This shows up, for example, in the animation in attachment 8384813
just halting at a corner if I'm careful not to disturb it. (I'm
testing on Linux, with both accelerated layers and OMT animations
explicitly enabled.)
I think there are probably some other things that can be removed as
followups to removing this code, because I think we made some boundary
conditions intentionally incorrect so that problem (3) above wouldn't be
as bad as it otherwise would have been.
The first provides a reasonable default (failure to parse) for the case
of an unknown value type (which should never happen).
The second reorders two failure checks so that the one that returns
early when units is uninitialized happens before the one that looks at
units.
In this crash test we restore the refresh driver after manually advancing it.
This causes a situation where a layer has an animation that has yet to start.
Prior to modifying ElementAnimations::GetPositionIteration this test case would
trip an assertion there that rejected negative elapsed times when called from
the compositor thread.
Rename NS_STYLE_CLEAR_LEFT_AND_RIGHT to NS_STYLE_CLEAR_BOTH. Also fix whitespace and remove unnecessary parens in a few places and enumerate the possible break types in an assertion so that it doesn't make assumptions on the actual property values.
This makes sense since the file no longer contains anything with the
nsTraceRefcnt name in it, and it will allow renaming nsTraceRefcntImpl
back to nsTraceRefcnt.
* 5.3.1: Blending between the background layers and the background color for an element with background-blend-mode. Most of section 5.3.1 is covered by other tests. Add the missing tests of the 5.3.1 section of the test plan.
- Test 9: SVG image and background color (SVG as data:uri)
- Test 10: Animated gif image and background color
- Test 12: background-blend-mode on element with 3D transform
* 5.3.2: Background layers do not blend with content outside the background (or behind the element).
- Implementation of tests 2 and 3. Test 1 is already covered by background-blending-isolation.html.
* 5.3.6: background-blend-mode for an element with background-position
* 5.3.7: background-blend-mode for an element with background-size
* 5.3.8: background-blend-mode for an element with background-repeat
* 5.3.9: background-blend-mode for an element with background-clip
* 5.3.10: background-blend-mode for an element with background-origin
* 5.3.11: background-blend-mode for an element with background-attachement
* Add extra tests for the background-blend-mode CSS property: Add some invalid values to the background-blend-mode property definition so that it can benefit from existing invalid property tests.
Prior to this patch, we failed to honor:
* margin-left on elements in inline layout with 0 width and 0 height
* margin-right on elements in inline layout with 0 width
I think that was because the code in CanPlaceFrame to discard both
margins when the width was 0 was running after the left-margin was
applied, unless the later code in PlaceFrame (checking both width 0 and
height 0) un-applied that left margin.
The assertion count change in test_value_computation.html is due to 2
additional "bad width" assertions (I presume from honoring large
margins that were previously ignored).
The change to 538935-1-ref.html is to match an improvement in rendering
of the margins in the test, where both sides of the margin are now
honored.
The change to layout/reftests/text-overflow/marker-basic-ref.html is to
keep the reference (which uses margins) rendering the same way following
the changes to margin handling.
The new behavior (in the reftests added in layout/reftests/inline/)
matches at least Chromium; I didn't check any other browsers.
