wine/gecko
0
0
Fork 0
mirror of https://gitlab.winehq.org/wine/wine-gecko.git synced 2024-09-13 09:24:08 -07:00
Code Issues Packages Projects Releases Wiki Activity
d32e919388
gecko/layout/style/test/test_animations_omta_start.html

133 lines
3.7 KiB
HTML
Raw Normal View History

Bug 975261 part 1 - Add test for OMTA animations that start with a delay; r=dzbarsky
2014-03-21 14:59:57 -07:00
<!DOCTYPE HTML>
<html>
<!--
https://bugzilla.mozilla.org/show_bug.cgi?id=975261
-->
<head>
<meta charset="utf-8">
<title>Test OMTA animations start correctly (Bug 975261)</title>
<script type="application/javascript"
src="/tests/SimpleTest/SimpleTest.js"></script>
<script type="application/javascript"
src="/tests/SimpleTest/paint_listener.js"></script>
Bug 964646 part 1 - Add common OMTA test runner to animation_utils.js; r=dbaron Since off-main thread animation (OMTA) is not available on all platforms we define a common wrapper function that runs OMTA tests only when available. This patch further performs an internal check of basic OMTA operation so that only a single error is produced if OMTA is unexpectedly unavailable. Typical usage is: SimpleTest.waitForExplicitFinish(); runOMTATest(function() { ... test code ... SimpleTest.finish(); }, SimpleTest.finish); This can be easily wrapped with promises if needed but does not require using promises. The calls to waitForExplicitFinish and finish are not performed automatically since this function may be integrated with test suites that do other work outside the call to runOMTATest.
2014-04-03 00:55:44 -07:00
<script type="application/javascript" src="animation_utils.js"></script>
Bug 975261 part 1 - Add test for OMTA animations that start with a delay; r=dzbarsky
2014-03-21 14:59:57 -07:00
<link rel="stylesheet" type="text/css" href="/tests/SimpleTest/test.css"/>
<style type="text/css">
Bug 975261 part 3 - Add test for transforms; r=dzbarsky 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.
2014-03-21 14:59:57 -07:00
@keyframes anim-opacity {
Bug 975261 part 1 - Add test for OMTA animations that start with a delay; r=dzbarsky
2014-03-21 14:59:57 -07:00
0% { opacity: 0.5 }
100% { opacity: 0.5 }
}
Bug 975261 part 3 - Add test for transforms; r=dzbarsky 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.
2014-03-21 14:59:57 -07:00
@keyframes anim-transform {
0% { transform: translate(50px); }
100% { transform: translate(50px); }
}
Bug 975261 part 4 - Add test for starting OMTA animations with backwards fill; r=dzbarsky 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.
2014-03-21 14:59:58 -07:00
@keyframes anim-transform-2 {
0% { transform: translate(0px); }
100% { transform: translate(100px); }
}
Bug 975261 part 1 - Add test for OMTA animations that start with a delay; r=dzbarsky
2014-03-21 14:59:57 -07:00
.target {
Bug 975261 part 3 - Add test for transforms; r=dzbarsky 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.
2014-03-21 14:59:57 -07:00
/* These two lines are needed so that an opacity/transform layer
* already exists when the animation is applied. */
opacity: 0.99;
transform: translate(99px);
/* Element needs geometry in order to be animated on the
* compositor. */
Bug 975261 part 1 - Add test for OMTA animations that start with a delay; r=dzbarsky
2014-03-21 14:59:57 -07:00
width: 100px;
height: 100px;
background-color: white;
}
</style>
</head>
<body>
<a target="_blank"
href="https://bugzilla.mozilla.org/show_bug.cgi?id=975261">Mozilla Bug
975261</a>
Bug 975261 part 4 - Add test for starting OMTA animations with backwards fill; r=dzbarsky 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.
2014-03-21 14:59:58 -07:00
<div id="display"></div>
Bug 975261 part 1 - Add test for OMTA animations that start with a delay; r=dzbarsky
2014-03-21 14:59:57 -07:00
<pre id="test">
<script type="application/javascript">
"use strict";
Bug 975261 part 4 - Add test for starting OMTA animations with backwards fill; r=dzbarsky 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.
2014-03-21 14:59:58 -07:00
var gUtils = SpecialPowers.DOMWindowUtils;
Bug 975261 part 1 - Add test for OMTA animations that start with a delay; r=dzbarsky
2014-03-21 14:59:57 -07:00
Bug 964646 part 1 - Add common OMTA test runner to animation_utils.js; r=dbaron Since off-main thread animation (OMTA) is not available on all platforms we define a common wrapper function that runs OMTA tests only when available. This patch further performs an internal check of basic OMTA operation so that only a single error is produced if OMTA is unexpectedly unavailable. Typical usage is: SimpleTest.waitForExplicitFinish(); runOMTATest(function() { ... test code ... SimpleTest.finish(); }, SimpleTest.finish); This can be easily wrapped with promises if needed but does not require using promises. The calls to waitForExplicitFinish and finish are not performed automatically since this function may be integrated with test suites that do other work outside the call to runOMTATest.
2014-04-03 00:55:44 -07:00
SimpleTest.waitForExplicitFinish();
runOMTATest(testDelay, SimpleTest.finish);
Bug 975261 part 1 - Add test for OMTA animations that start with a delay; r=dzbarsky
2014-03-21 14:59:57 -07:00
Bug 975261 part 4 - Add test for starting OMTA animations with backwards fill; r=dzbarsky 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.
2014-03-21 14:59:58 -07:00
function newTarget() {
var target = document.createElement("div");
target.classList.add("target");
document.getElementById("display").appendChild(target);
return target;
}
Bug 975261 part 1 - Add test for OMTA animations that start with a delay; r=dzbarsky
2014-03-21 14:59:57 -07:00
function testDelay() {
Bug 975261 part 4 - Add test for starting OMTA animations with backwards fill; r=dzbarsky 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.
2014-03-21 14:59:58 -07:00
gUtils.advanceTimeAndRefresh(0);
Bug 975261 part 1 - Add test for OMTA animations that start with a delay; r=dzbarsky
2014-03-21 14:59:57 -07:00
Bug 975261 part 4 - Add test for starting OMTA animations with backwards fill; r=dzbarsky 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.
2014-03-21 14:59:58 -07:00
var target = newTarget();
target.setAttribute("style", "animation: 10s 10s anim-opacity linear");
gUtils.advanceTimeAndRefresh(0);
Bug 975261 part 1 - Add test for OMTA animations that start with a delay; r=dzbarsky
2014-03-21 14:59:57 -07:00
Bug 975261 part 3 - Add test for transforms; r=dzbarsky 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.
2014-03-21 14:59:57 -07:00
waitForAllPaints(function() {
Bug 975261 part 4 - Add test for starting OMTA animations with backwards fill; r=dzbarsky 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.
2014-03-21 14:59:58 -07:00
gUtils.advanceTimeAndRefresh(10100);
Bug 975261 part 1 - Add test for OMTA animations that start with a delay; r=dzbarsky
2014-03-21 14:59:57 -07:00
waitForAllPaints(function() {
Bug 975261 part 4 - Add test for starting OMTA animations with backwards fill; r=dzbarsky 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.
2014-03-21 14:59:58 -07:00
var opacity = gUtils.getOMTAStyle(target, "opacity");
Bug 975261 part 2 - Trigger animations with a delay; r=dzbarsky 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.
2014-03-21 14:59:57 -07:00
is(opacity, 0.5,
"opacity is set on compositor thread after delayed start");
Bug 975261 part 4 - Add test for starting OMTA animations with backwards fill; r=dzbarsky 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.
2014-03-21 14:59:58 -07:00
target.removeAttribute("style");
gUtils.restoreNormalRefresh();
Bug 975261 part 3 - Add test for transforms; r=dzbarsky 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.
2014-03-21 14:59:57 -07:00
testTransform();
});
});
}
function testTransform() {
Bug 975261 part 4 - Add test for starting OMTA animations with backwards fill; r=dzbarsky 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.
2014-03-21 14:59:58 -07:00
gUtils.advanceTimeAndRefresh(0);
Bug 975261 part 3 - Add test for transforms; r=dzbarsky 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.
2014-03-21 14:59:57 -07:00
Bug 975261 part 4 - Add test for starting OMTA animations with backwards fill; r=dzbarsky 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.
2014-03-21 14:59:58 -07:00
var target = newTarget();
target.setAttribute("style", "animation: 10s 10s anim-transform linear");
gUtils.advanceTimeAndRefresh(0);
Bug 975261 part 3 - Add test for transforms; r=dzbarsky 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.
2014-03-21 14:59:57 -07:00
waitForAllPaints(function() {
Bug 975261 part 4 - Add test for starting OMTA animations with backwards fill; r=dzbarsky 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.
2014-03-21 14:59:58 -07:00
gUtils.advanceTimeAndRefresh(10100);
Bug 975261 part 3 - Add test for transforms; r=dzbarsky 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.
2014-03-21 14:59:57 -07:00
waitForAllPaints(function() {
Bug 975261 part 4 - Add test for starting OMTA animations with backwards fill; r=dzbarsky 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.
2014-03-21 14:59:58 -07:00
var transform = gUtils.getOMTAStyle(target, "transform");
Bug 975261 part 3 - Add test for transforms; r=dzbarsky 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.
2014-03-21 14:59:57 -07:00
is(transform, "matrix(1, 0, 0, 1, 50, 0)",
"transform is set on compositor thread after delayed start");
Bug 975261 part 4 - Add test for starting OMTA animations with backwards fill; r=dzbarsky 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.
2014-03-21 14:59:58 -07:00
target.removeAttribute("style");
gUtils.restoreNormalRefresh();
testBackwardsFill();
});
});
}
function testBackwardsFill() {
gUtils.advanceTimeAndRefresh(0);
var target = newTarget();
target.setAttribute("style",
"transform: translate(30px); " +
"animation: 10s 10s anim-transform-2 linear backwards");
gUtils.advanceTimeAndRefresh(0);
waitForAllPaints(function() {
gUtils.advanceTimeAndRefresh(10000);
waitForAllPaints(function() {
gUtils.advanceTimeAndRefresh(100);
waitForAllPaints(function() {
var transform = gUtils.getOMTAStyle(target, "transform");
Bug 975261 part 5 - Fix OMTA animations with backwards fill; r=dzbarsky 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).
2014-03-21 14:59:58 -07:00
is(transform, "matrix(1, 0, 0, 1, 1, 0)",
"transform is set on compositor thread after delayed start " +
"with backwards fill");
Bug 975261 part 4 - Add test for starting OMTA animations with backwards fill; r=dzbarsky 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.
2014-03-21 14:59:58 -07:00
target.removeAttribute("style");
gUtils.restoreNormalRefresh();
SimpleTest.finish();
});
Bug 975261 part 1 - Add test for OMTA animations that start with a delay; r=dzbarsky
2014-03-21 14:59:57 -07:00
});
});
}
</script>
</pre>
</body>
</html>
Reference in New Issue Copy Permalink