Referenced SVG all wibbly-wobby when nothing is supposed to change
Reported by
philipp....@gmail.com,
Aug 8 2017
|
||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.31 Safari/537.36 Steps to reproduce the problem: See http://bl.ocks.org/Herst/da06ec62b68939d9b4a67e9feed6ccf3 for a testcase. Zoom in for a more massive effect. What is the expected behavior? When preserveAspectRatio is set to a certain value so that the aspect ratio is kept and the position of the image unchanged as the length of a certain side is increased (e.g. as in the test case increasing the width above a certain point while the size is limited by the height and preserveAspectRatio set so that the image stays on the left side) then there should be no visible change in the image. What went wrong? Parts of the image are moving erratically or being stretched/squeezed (wibbly-wobbly), which looks like something which is the effect of rounding/quantization errors. Worse of all, the effect increases with increased zooming. Did this work before? No Does this work in other browsers? No In Mozilla Firefox the wibbly-wobbliness also occurs but does not intensify when the zoom level is increased. In Microsoft Internet Explorer and Microsoft Edge the issue does not occur. Chrome version: 61.0.3163.31 Channel: beta OS Version: 10.0 Flash Version: (This is a real problem I am seeing in a d3.js-heavy project.)
,
Aug 9 2017
,
Aug 9 2017
Tested the issue on chrome Beta #61.0.3163.31 and Canary #62.0.3180.0 in Windows 7 and was able to reproduce the issue. This is a Non-Regression issue since seeing this from M45 #45.0.2404.0, Making the status to Untriaged so that the issue would get addressed. Note : Able to reproduce the issue in MAC 10.12.6 and Linux Ubuntu 14.04. Thank you.
,
Aug 9 2017
We seem to be computing something off the width then using it for the height, when the height is the thing that is stable. My guess is that we are using round when we should be flooring, but I also suspect that other stuff will break if we change it.
,
Aug 10 2017
I simplified the test case a little bit and added a red <rect> below the embedded SVG which when visible also points towards a problem. (On a side note, the font behaves better now, maybe it played a role that in the old version the font size was 5px but transformed up.)
,
Aug 11 2017
Forget what I previously said about fonts, it might be dependent on platform/font. Attached is a video showing the original issue (and while at it also showing also the font issue on a Linux desktop platform, the distro is OpenSUSE Tumbleweed and the font is Liberation Serif.)
,
Aug 14 2017
Standalone link for testing (taken from iFrame in original link) http://bl.ocks.org/Herst/raw/da06ec62b68939d9b4a67e9feed6ccf3/8ccae8ad6b3f37c297684fd326308df436cce148/
,
Aug 14 2017
The fundamental problem is that platform/Image only handles integer sizes, which forces rounding of SVG and other generated image content. We then use the rounded values in computing the aspect ratio which generates floating point values for painting. If the underlying image size was not rounded, the aspect ratio calculations would probably be close to an integer in this case. I think it might be time to finally change blink::Image to report floating point sizes.
,
Sep 15 2017
Firefox (Gecko) bug report for similar (but less pronounced) issue: https://bugzil.la/1394148 |
||||
►
Sign in to add a comment |
||||
Comment 1 by pbomm...@chromium.org
, Aug 8 2017Labels: Needs-Triage-M61