New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 20 users
Status: Fixed
Owner:
Closed: Dec 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug



Sign in to add a comment
CSS matrix3d transform inconsistent under full page zoom
Project Member Reported by deanm@chromium.org, May 21 2013 Back to list
Version: 26.0.1410.65
OS: OSX 10.8.3

What steps will reproduce the problem?
1. Open csszoombug.html
2. Notice that the blue shape touches the edges of the red square
3. Now zoom out a few times (apple minus)

What is the expected output? What do you see instead?

I would expect that the page zooms together, instead the elements shift from each other.
 
csszoombug.html
505 bytes View Download
Comment 1 by tkent@chromium.org, May 22 2013
Labels: Cr-Blink-CSS-3D
Cc: enne@chromium.org vangelis@chromium.org vollick@chromium.org
Thanks for reporting.  I tried to bisect without meaningful results.  This also reproduces on Safari, so the bug is somewhere in Blink/WebKit.

I suspect it's a bug with how composited-layer positions are computed in RenderLayerBacking.
Some more information; it seems the bug is isolated to only transforms using matrices. When decomposed, the individual transforms are resilient to page zooms.

See attached file with a similar transform but decomposed.
csszoombug-decomposed.html
450 bytes View Download
Comment 4 by mbost...@gmail.com, Apr 14 2014
Here is another demonstration of this problem:

http://bl.ocks.org/mbostock/c02ccf25704d434cebd1

The cyan grid is transformed manually by multiplying the matrix in JavaScript, while the underlying magenta grid is transformed using a CSS matrix3d transform. Normally the cyan grid exactly overlays the magenta grid. However, they become detached when the page is zoomed.

FWIW, the same bug affects Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=995871 (Firefox is also affected on Retina displays, but Chrome is not.)
Any update on this?
 
Here's another (admittedly experimental) website that suffers from this issue: http://vm-1202-user.virt.ch.bbc.co.uk/react_ballet_x3d.html

Observe how the 3D labels are rendered out of alignment when the browser zoom level is changed by the user.
Cc: awoloszyn@chromium.org
Comment 7 by enne@chromium.org, Apr 2 2015
Labels: Hotlist-GoodFirstBug
I wonder if the problem is that Blink is applying the matrix in post-page scale space, and so elements that have a transform with any sort of perspective start behaving non-linearly.  As page zoom isn't really observable from Javascript in the sense that widths don't change, I think this is a bug.  Probably the page zoom needs to be included somewhere before/after the the transform to make this correct.

This is quite unfortunate, but it isn't really a high priority bug.
Another - short example:

http://jsfiddle.net/kardaw/cjt5uu3e/

The Issue does not apply to Firefox and Edge.
example.html
897 bytes View Download
image.png
10.2 KB View Download
Cc: -awoloszyn@chromium.org
Labels: Hotlist-Polish
Owner: petermayo@chromium.org
Comment 10 by fta2...@gmail.com, Nov 6 2016
Submitted a fix for this in https://codereview.chromium.org/2482753002/
Cc: pfeldman@chromium.org
 Issue 661955  has been merged into this issue.
Project Member Comment 12 by bugdroid1@chromium.org, Nov 10 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/6be6a794e7ea4dcc2b9e12da2aa02d00b3c84f1c

commit 6be6a794e7ea4dcc2b9e12da2aa02d00b3c84f1c
Author: fta2012 <fta2012@gmail.com>
Date: Thu Nov 10 08:13:58 2016

Fix matrix3d transform under page zoom

The math for adjusting a matrix3d transform when the page is zoomed is incorrect in at least 3 different places.

There was a previous attempt at fixing this but they did it the same way as the 2d matrix case and forgot about the translateZ component (ceddaab902432728b12a17fcbf2c42283c7dfe68). But it would've been incorrect even if they did take translateZ into account.

The real problem is that the last column can't be interpeted as the translation at all if the matrix is non-affine!

To get the general correction for matrix3d, intuitively, we want to first scale down to the original units, do the transform, then scale back up. So checking with octave/matlab it should actually be:

    octave:1> pkg load symbolic;
    octave:2> A = sym('a', [3, 3]); B = sym('b', [3, 1]); C = sym('c', [1, 3]); D = sym('d', [1, 1]); s = sym('s');
    octave:3> M = [A, B; C D]
    M = (sym 4×4 matrix)

      ⎡a₁₁  a₁₂  a₁₃  b₁₁⎤
      ⎢                  ⎥
      ⎢a₂₁  a₂₂  a₂₃  b₂₁⎥
      ⎢                  ⎥
      ⎢a₃₁  a₃₂  a₃₃  b₃₁⎥
      ⎢                  ⎥
      ⎣c₁₁  c₁₂  c₁₃  d₁₁⎦

    octave:4> scaleDown = [[eye(3) / s, zeros(3, 1)]; [zeros(1, 3), 1]]
    scaleDown = (sym 4×4 matrix)

      ⎡1         ⎤
      ⎢─  0  0  0⎥
      ⎢s         ⎥
      ⎢          ⎥
      ⎢   1      ⎥
      ⎢0  ─  0  0⎥
      ⎢   s      ⎥
      ⎢          ⎥
      ⎢      1   ⎥
      ⎢0  0  ─  0⎥
      ⎢      s   ⎥
      ⎢          ⎥
      ⎣0  0  0  1⎦

    octave:5> scaleUp = [[s * eye(3), zeros(3, 1)]; [zeros(1, 3), 1]]
    scaleUp = (sym 4×4 matrix)

      ⎡s  0  0  0⎤
      ⎢          ⎥
      ⎢0  s  0  0⎥
      ⎢          ⎥
      ⎢0  0  s  0⎥
      ⎢          ⎥
      ⎣0  0  0  1⎦

    octave:6> scaleUp * M * scaleDown
    ans = (sym 4×4 matrix)

      ⎡a₁₁  a₁₂  a₁₃  b₁₁⋅s⎤
      ⎢                    ⎥
      ⎢a₂₁  a₂₂  a₂₃  b₂₁⋅s⎥
      ⎢                    ⎥
      ⎢a₃₁  a₃₂  a₃₃  b₃₁⋅s⎥
      ⎢                    ⎥
      ⎢c₁₁  c₁₂  c₁₃       ⎥
      ⎢───  ───  ───   d₁₁ ⎥
      ⎣ s    s    s        ⎦

So in the above matrix, if it is affine (which is exactly when the `c` entries are 0 and `d` is 1) you can get away with just scaling the last column interpreting `b` as the translation.

But for a general matrix3d you still need a few more divides on the bottom row!

Sidenote: The perspective transform is the only other CSS transform that is non-affine and it gets the zoom division implicitly when the parameter is scaled up since it's in the form of:

  ⎡1  0   0   0⎤
  ⎢            ⎥
  ⎢0  1   0   0⎥
  ⎢            ⎥
  ⎢0  0   1   0⎥
  ⎢            ⎥
  ⎢      -1    ⎥
  ⎢0  0  ───  1⎥
  ⎣       p    ⎦

The reported issue is solved by fixing TransformBuilder as described above. But the same type of bug also appeared in getComputedStyle and animations with matrix3d. I also fixed them in this CL but a longer term solution should probably refactor all them (maybe into TransformOperation::zoom) so that this tricky bit of logic isn't duplicated in so many places.

BUG= 242685 
R=pdr,alancutter

Review-Url: https://codereview.chromium.org/2482753002
Cr-Commit-Position: refs/heads/master@{#431208}

[modify] https://crrev.com/6be6a794e7ea4dcc2b9e12da2aa02d00b3c84f1c/AUTHORS
[modify] https://crrev.com/6be6a794e7ea4dcc2b9e12da2aa02d00b3c84f1c/third_party/WebKit/LayoutTests/animations/zoom-responsive-transform-animation-expected.html
[modify] https://crrev.com/6be6a794e7ea4dcc2b9e12da2aa02d00b3c84f1c/third_party/WebKit/LayoutTests/animations/zoom-responsive-transform-animation.html
[modify] https://crrev.com/6be6a794e7ea4dcc2b9e12da2aa02d00b3c84f1c/third_party/WebKit/LayoutTests/fast/css/getComputedStyle/computed-style-with-zoom-expected.txt
[modify] https://crrev.com/6be6a794e7ea4dcc2b9e12da2aa02d00b3c84f1c/third_party/WebKit/LayoutTests/fast/css/getComputedStyle/script-tests/computed-style-with-zoom.js
[modify] https://crrev.com/6be6a794e7ea4dcc2b9e12da2aa02d00b3c84f1c/third_party/WebKit/LayoutTests/transforms/3d/general/cssmatrix-3d-zoom-expected.png
[modify] https://crrev.com/6be6a794e7ea4dcc2b9e12da2aa02d00b3c84f1c/third_party/WebKit/LayoutTests/transforms/3d/general/cssmatrix-3d-zoom.html
[modify] https://crrev.com/6be6a794e7ea4dcc2b9e12da2aa02d00b3c84f1c/third_party/WebKit/Source/core/css/ComputedStyleCSSValueMapping.cpp
[modify] https://crrev.com/6be6a794e7ea4dcc2b9e12da2aa02d00b3c84f1c/third_party/WebKit/Source/core/css/resolver/TransformBuilder.cpp
[modify] https://crrev.com/6be6a794e7ea4dcc2b9e12da2aa02d00b3c84f1c/third_party/WebKit/Source/platform/transforms/Matrix3DTransformOperation.cpp
[modify] https://crrev.com/6be6a794e7ea4dcc2b9e12da2aa02d00b3c84f1c/third_party/WebKit/Source/platform/transforms/TransformOperationsTest.cpp
[modify] https://crrev.com/6be6a794e7ea4dcc2b9e12da2aa02d00b3c84f1c/third_party/WebKit/Source/platform/transforms/TransformationMatrix.cpp
[modify] https://crrev.com/6be6a794e7ea4dcc2b9e12da2aa02d00b3c84f1c/third_party/WebKit/Source/platform/transforms/TransformationMatrix.h

So any update on the fix and when will it be available? :)
The above change looks to me like it is on branch 56, but not 55.

So depending on what channel you're asking about, that sets the time frame.

I'm not dialed right into when the releases hit where right now, but I think stable is 54, so dev should be 56 and already have it.  Check your channel and version.  The release cycle is about six weeks, and is slowed down over the year-end.

I haven't verified that the change fixes all the problems yet.
Status: Fixed
This looks like it is fixed in M 56 to me.

Leaving to reporter or test to move to verified.
Labels: M-56
Cc: fta2...@gmail.com rbyers@chromium.org pdr@chromium.org petermayo@chromium.org
 Issue 668753  has been merged into this issue.
Comment 18 by suzyh@chromium.org, Mar 24 2017
Components: -Blink>CSS>CSS3D Blink>Compositing>Transform3D
Sign in to add a comment