When we have a backwards fill and we sample at *exactly* the start of the
animation on the next refresh driver tick, when we get to
RestyleManager::ComputeStyleChangeFor (or more specifically
ElementRestyler::CaptureChange) we notice that the style hasn't changed (since
the first frame of the animation produces the same value as the backwards fill)
and end up with an empty change list. As a result we never schedule a view
manager flush and rebuild the layer. Hence, the animation never gets sent to the
compositor thread. On the next tick we're already throttling the main thread.
This patch fixes this by applying the same approach as is used for transitions,
that is, explicitly marking which animations are running on the compositor
thread so we know if we need to trigger a layer transaction or not. This should
not only be more robust than the previous code but also facilitate aligning
animations and transitions code (bug 880596).
This test reproduces a bug where we don't send an animation to the compositor
thread. The important step is the sample precisely at the start of the animation
interval.
Adds a test for transform animations with a delay where there is already
a transform specified on the element.
This test used to fail but bug 828173 fixed it. It is included here as
a regression test.
(Prior to bug 828173 we were able to fix this by triggering
ForceLayerRerendering inside nsAnimationManager::nsFlushAnimations whenever we
detected *different* style rules but canThrottleTick=true)
The issue stemmed from the fact that when an element has a transform property,
LayerIsPrerenderedDataKey would get set on the layer because in
nsDisplayTransform::ShouldPrerenderTransformedContent we would only check for
the *presence* of an animation, not whether it is running. Then in
RestyleManager::DoApplyRenderingChangeToTree we wouldn't do an invalidating
paint because TryUpdateTransformOnly() returns true since it looks at
LayerIsPrerenderedDataKey.
Bug 828173 fixes this, at least in part, by checking if an animation is running.
This bug may resurface if we put animations with a delay on the compositor
thread hence it is worth including here.
Animations with a delay are not put on the compositor thread until the end of
the delay phase. However, there is currently nothing that explicitly triggers
this transaction. It may occur due to flushes that arise from UI events but it
is not guaranteed.
This patch detects the end of a delay phase and turns off throttling for that
sample. It re-uses the mLastNotification member which is not ideal but
a subsequent patch in this queue removes this and replaces it with the approach
used for transitions.
* 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.
Ideally we'd make this property inaccessible to Web content style sheets, but
that seems hard since view-source and plain text documents seem to load in a
context that's very similar to Web content as far as the style system is
concerned. It doesn't matter much since it's quite safe and unlikely to be
discovered or used by anyone.
--HG--
extra : rebase_source : 009aafc992afd07fd76a9026afe0f6994b4b214a
