Bug 1568324 [wpt PR 18013] - Composite color values on the worklet thread, a=testonly
authorAdam Raine <asraine@google.com>
Sat, 24 Aug 2019 09:58:18 +0000
changeset 553843 6e1dcbe925421c39cb7981354f13d7219506ffdd
parent 553842 d8ec210f26bdce38b5b4aaed5be98a9bd4226ada
child 553844 b4ec189f388b153b357f95f34aa42bfba53db8cf
push id2165
push userffxbld-merge
push dateMon, 14 Oct 2019 16:30:58 +0000
treeherdermozilla-release@0eae18af659f [default view] [failures only]
perfherder[talos] [build metrics] [platform microbench] (compared to previous push)
reviewerstestonly
bugs1568324, 18013, 1614120, 1698667, 883721, 1713747, 687702
milestone70.0a1
first release with
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
last release without
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
Bug 1568324 [wpt PR 18013] - Composite color values on the worklet thread, a=testonly Automatic update from web-platform-tests Composite color values on the worklet thread Follow up to: https://chromium-review.googlesource.com/c/chromium/src/+/1614120 (Allows number values to be composited on the worklet thread) --and-- https://chromium-review.googlesource.com/c/chromium/src/+/1698667 (Allows creation of keyframe model for color values on compositor) This CL adds similar functionality as that used for number types to update color values on the compositor. New classes CrossThreadColorValue and CSSUnsupportedColorValue were created for CSSPaintValue::GetImage to identify color valued custom properties as compositable. Bug: 883721 Change-Id: Ib8c26e5c6c6077b21288de3156fa35cc6e02435d Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1713747 Commit-Queue: Adam Raine <asraine@google.com> Reviewed-by: Rune Lillesveen <futhark@chromium.org> Reviewed-by: Stephen McGruer <smcgruer@chromium.org> Reviewed-by: Xida Chen <xidachen@chromium.org> Cr-Commit-Position: refs/heads/master@{#687702} -- wpt-commits: 7c42039e0623abaae97105214e9968c92272f15d wpt-pr: 18013
testing/web-platform/tests/css/css-paint-api/color-custom-property-animation-ref.html
testing/web-platform/tests/css/css-paint-api/color-custom-property-animation.https.html
new file mode 100644
--- /dev/null
+++ b/testing/web-platform/tests/css/css-paint-api/color-custom-property-animation-ref.html
@@ -0,0 +1,12 @@
+<!DOCTYPE html>
+<html>
+<body>
+<canvas id ="canvas" width="100" height="100"></canvas>
+<script>
+var canvas = document.getElementById('canvas');
+var context = canvas.getContext("2d");
+context.fillStyle = 'rgb(127, 127, 0)';
+context.fillRect(0, 0, 100, 100);
+</script>
+</body>
+</html>
new file mode 100644
--- /dev/null
+++ b/testing/web-platform/tests/css/css-paint-api/color-custom-property-animation.https.html
@@ -0,0 +1,57 @@
+<!DOCTYPE html>
+<html class="reftest-wait">
+<link rel="help" href="https://drafts.css-houdini.org/css-paint-api/">
+<link rel="match" href="color-custom-property-animation-ref.html">
+<style>
+.container {
+  width: 100px;
+  height: 100px;
+  animation: expand 5s;
+  will-change: transform;
+}
+@keyframes expand {
+  0% { --foo: rgb(255, 0, 0); }
+  0.01% { --foo: rgb(127, 127, 0); }
+  99% { --foo: rgb(127, 127, 0); }
+  100% { --foo: rgb(0, 255, 0); }
+}
+
+#canvas-geometry {
+  background-image: paint(geometry);
+}
+</style>
+<script src="/common/reftest-wait.js"></script>
+<script src="/common/worklet-reftest.js"></script>
+<body>
+<div id="canvas-geometry" class="container"></div>
+
+<script id="code" type="text/worklet">
+registerPaint('geometry', class {
+  static get inputProperties() { return ['--foo']; }
+  paint(ctx, geom, properties) {
+    ctx.fillStyle = properties.get('--foo').toString();
+    ctx.fillRect(0, 0, 100, 100);
+  }
+});
+</script>
+
+<script>
+CSS.registerProperty({
+  name: '--foo',
+  syntax: '<color>',
+  initialValue: 'rgb(0, 0, 0)',
+  inherits: false
+});
+</script>
+
+<script>
+// The test is designed to make sure that when the custom property animation is
+// running on the compositor thread, we are getting the right value.
+// The "importWorkletAndTerminateTestAfterAsyncPaint" has the logic to rAF
+// two frames before taking a screenshot. So the animation is designed to
+// be stable after two frames. That is, the 0.01% of 5s is much less than
+// two frames, and thus after two frames, the value of --foo should be stable.
+importWorkletAndTerminateTestAfterAsyncPaint(CSS.paintWorklet, document.getElementById('code').textContent);
+</script>
+</body>
+</html>