Css Transformations for Matrices
Reported by
dragons6...@gmail.com,
Dec 23 2017
|
|||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3301.0 Safari/537.36 Steps to reproduce the problem: 1. Apply a transition to an object transformed with a matrix What is the expected behavior? The transition should be applied to the bounding box; you can try this with firefox to see the behaviour that I'd expect. What went wrong? The triangle seems to follow the arc of a circle, this is possibly because the transition is applied relative to the origin of the svg, whereas it should be applied to move the current bounding box to the new bounding box. Did this work before? N/A Does this work in other browsers? Yes Chrome version: 65.0.3301.0 Channel: canary OS Version: OS X 10.12.6 Flash Version:
,
Dec 23 2017
Oops, yep I forgot to get rid of the transform-origin. I was trying to fix the issue but forgot to remove it before filing the report.
,
Dec 26 2017
,
Dec 28 2017
Safari and Firefox [and Edge for non-SVG elements] have common behavior. Confirmed that Chrome behaves differently, and that this isn't a regression.
,
Nov 6
,
Nov 15
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/e08eb1644a55fb33111b0734d783e20b7017b413 commit e08eb1644a55fb33111b0734d783e20b7017b413 Author: Kevin Ellis <kevers@chromium.org> Date: Thu Nov 15 17:38:00 2018 Improve robustness of transform-post-multiplication test. The transform-post-multiplication testis very sensitive to changes in 2D matrix interpolation. This patch addresses the following: * Use a prefix that guarantees that matrix and pairwise interpolation product different transforms. Previously relying on subtle numerical precision discrepancies. With the new prefix, pairwise will scale and transform will rotate. * Fix matrix comparison to consider the full floating point value and not just the mantissa. Previously small non-zero values would be perceived as a matrix mismatch. Bug: 797472 Change-Id: I9120f2f92195cf2559ff2eb4294e1341195c277e Reviewed-on: https://chromium-review.googlesource.com/c/1337639 Reviewed-by: Stephen McGruer <smcgruer@chromium.org> Commit-Queue: Kevin Ellis <kevers@chromium.org> Cr-Commit-Position: refs/heads/master@{#608417} [modify] https://crrev.com/e08eb1644a55fb33111b0734d783e20b7017b413/third_party/WebKit/LayoutTests/animations/transform-post-multiplication.html
,
Nov 15
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/0688b8a4b05ab68b0fd77b33b10e64e19d767a12 commit 0688b8a4b05ab68b0fd77b33b10e64e19d767a12 Author: Kevin Ellis <kevers@chromium.org> Date: Thu Nov 15 19:06:58 2018 Improve robustness of wpt animation interpolation tests. This patch fixes the problem where subtle changes to numerical values in matrix interpolation cause mismatches in the expected results. To address the issue: * Styles are checked to see if they are of the form matrix(...) or matrix3d(...). * If the style is a matrix, then arguments are rounded and the style is reconstructed. Bug: 797472 Change-Id: I44d6e0ed13e24dc2ecfeeacbcd4809d6dcdb6465 Reviewed-on: https://chromium-review.googlesource.com/c/1337640 Reviewed-by: Xida Chen <xidachen@chromium.org> Commit-Queue: Kevin Ellis <kevers@chromium.org> Cr-Commit-Position: refs/heads/master@{#608466} [modify] https://crrev.com/0688b8a4b05ab68b0fd77b33b10e64e19d767a12/third_party/WebKit/LayoutTests/external/wpt/css/css-transforms/animation/list-interpolation-expected.txt [modify] https://crrev.com/0688b8a4b05ab68b0fd77b33b10e64e19d767a12/third_party/WebKit/LayoutTests/external/wpt/css/css-transforms/animation/matrix-interpolation-expected.txt [modify] https://crrev.com/0688b8a4b05ab68b0fd77b33b10e64e19d767a12/third_party/WebKit/LayoutTests/external/wpt/css/css-transforms/animation/resources/interpolation-testcommon.js
,
Nov 19
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/cab4d63402cb35f0080387a9ba5ed654ec3ab57b commit cab4d63402cb35f0080387a9ba5ed654ec3ab57b Author: Kevin Ellis <kevers@chromium.org> Date: Mon Nov 19 15:11:13 2018 Update tests of 2-D interpolation. The patch makes it possible to sanity check the interpolation paths for 2-D matrix transformations. The decomposition of a 2-D or a 3-D matrix is not unique, and can therefore affect the interpolation path. For example, negative scaling and rotation can be interchanged in some combinations. By restricting the tests to transforms produced by a restricted set of 2-D geometric operations, we can highlight cases where there is a preferred decomposition, and more easily flag regressions. Bug: 797472 Change-Id: Ic7d240ae6978e25aded183ea811c76a179f1e16a Reviewed-on: https://chromium-review.googlesource.com/c/1340941 Reviewed-by: Stephen McGruer <smcgruer@chromium.org> Commit-Queue: Kevin Ellis <kevers@chromium.org> Cr-Commit-Position: refs/heads/master@{#609293} [modify] https://crrev.com/cab4d63402cb35f0080387a9ba5ed654ec3ab57b/third_party/WebKit/LayoutTests/animations/interpolation/transform-interpolation-005.html [modify] https://crrev.com/cab4d63402cb35f0080387a9ba5ed654ec3ab57b/third_party/WebKit/LayoutTests/animations/interpolation/webkit-transform-interpolation-005.html
,
Dec 3
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/18d38f290c89dd430c6273a46f4ea21d0a9b7737 commit 18d38f290c89dd430c6273a46f4ea21d0a9b7737 Author: Kevin Ellis <kevers@chromium.org> Date: Mon Dec 03 19:25:50 2018 Simplify interpolation of 2-D matrix transforms. The decomposition of a transformation matrix into translations, rotation, scale and skew transforms is not unique. In some cases, the generalized 3-D decomposition does not align with the working draft for CSS transforms (https://drafts.csswg.org/css-transforms/). In the special case where the transforms being interpolated are both 2-D, a simplified model provides more restricted set of decomposition transforms with less computational overhead. Bug: 797472 Change-Id: I2b8ba99fe02c2eef878d94f5dfaea55c39652759 Reviewed-on: https://chromium-review.googlesource.com/c/1332253 Commit-Queue: Kevin Ellis <kevers@chromium.org> Commit-Queue: Ian Vollick <vollick@chromium.org> Reviewed-by: Ian Vollick <vollick@chromium.org> Cr-Commit-Position: refs/heads/master@{#613191} [modify] https://crrev.com/18d38f290c89dd430c6273a46f4ea21d0a9b7737/third_party/blink/renderer/platform/transforms/DEPS [modify] https://crrev.com/18d38f290c89dd430c6273a46f4ea21d0a9b7737/third_party/blink/renderer/platform/transforms/transformation_matrix.cc [modify] https://crrev.com/18d38f290c89dd430c6273a46f4ea21d0a9b7737/third_party/blink/renderer/platform/transforms/transformation_matrix.h [modify] https://crrev.com/18d38f290c89dd430c6273a46f4ea21d0a9b7737/third_party/blink/renderer/platform/transforms/transformation_matrix_test.cc [modify] https://crrev.com/18d38f290c89dd430c6273a46f4ea21d0a9b7737/third_party/blink/web_tests/external/wpt/web-animations/animation-model/animation-types/accumulation-per-property-expected.txt [modify] https://crrev.com/18d38f290c89dd430c6273a46f4ea21d0a9b7737/third_party/blink/web_tests/external/wpt/web-animations/animation-model/animation-types/interpolation-per-property-expected.txt [modify] https://crrev.com/18d38f290c89dd430c6273a46f4ea21d0a9b7737/third_party/blink/web_tests/external/wpt/web-animations/animation-model/animation-types/property-list.js
,
Dec 4
|
|||||
►
Sign in to add a comment |
|||||
Comment 1 by woxxom@gmail.com
, Dec 23 2017All versions of Chrome are affected since as early as v23. Chrome's implementation of matrix() is incorrect in case scaling traverses the 0 point. The matrix in the test case is basically scaleX(1) -> scaleX(-1) and Chrome handles direct scaling correctly: g { transform: scaleX(1) translate(100px,150px); transition: all 1s ease; transform-origin: 250px 200px; } .move { fill: red; transform: scaleX(-1) translate(100px,150px); } The only other workaround is to split the transformation matrix at zero point, which is very inconvenient since 0 is not animatable and it would have to be 1 to 0.00000001 and -0.0000001 to -1. P.S. "transform-origin" in #0 has invalid syntax, but that wasn't what caused the problem here.