SVG rect stroke not rendered in some cases
Reported by
mtyaka@gmail.com,
Sep 13
|
||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:62.0) Gecko/20100101 Firefox/62.0 Example URL: https://jsfiddle.net/fj0wr59m/35/ Steps to reproduce the problem: 1. Open https://jsfiddle.net/fj0wr59m/35/ in Chrome on macOS or Android 2. See that the the stroke fails to get rendered on the top rectangle What is the expected behavior? The stroke should get rendered on both rectangles. What went wrong? It seems that when both `rx` and `ry` attributes of a `<rect>` element are set to exactly half of the value of `stroke-width`, the stroke fails to get rendered. The actual value of `rx`, `ry`, and `stroke-width` does not seem to matter as long as `rx` and `ry` have the same value and `stroke-width` equals two times that value. In the provided example `rx` and `ry` are set to `10` and `stroke-width` is set to 20. In the example, the rectangle with correctly rendered stroke has a `stroke-width` set to 21, but it looks like any value other than 20 works correctly. The values of `width` and `height` on the `<svg>` element do matter. It looks like the bug is triggered if any of them has a decimal part which is larger than around 0.016. For example `width="300"` does not trigger the bug, but "width="300.02" does trigger it. The actual value of `width` and `height` does not seem to matter, the bug is always triggered as long as one of them contains a decimal part larger than ~ 0.016. Does it occur on multiple sites: Yes Is it a problem with a plugin? No Did this work before? Yes Chrome 52 - tested on BrowserStack Does this work in other browsers? Yes Chrome version: 69.0.3497.92 (Official Build) (64-bit) Channel: stable OS Version: OS X 10.13 Flash Version: Shockwave Flash 28.0 r0 The bug can be reproduced on macOS and Android. I wasn't able to reproduce it on Windows (using BrowserStack). Did not test in Linux.
,
Sep 13
,
Sep 14
,
Sep 14
Able to reproduce the issue on Mac 10.13.3 and Win-10 using chrome reported version #69.0.3497.92 and latest canary #71.0.3551.3. Issue is not seen in OS-linux. This is a non-regression issue as it is observed from M60 old builds. Hence, marking it as untriaged to get more inputs from dev team. Thanks...!!
,
Sep 14
Does the problem go away if you disable GPU acceleration? (If it is enabled in the first place that is.)
,
Sep 14
Yes, I just tried this on Mac - turning off "Use hardware acceleration when available" makes the problem go away.
,
Sep 14
,
Sep 14
Looks like this has been around a long time. Bisect says: You are probably looking for a change made after 384577 (known good), but no later than 384581 (first known bad). CHANGELOG URL: https://chromium.googlesource.com/chromium/src/+log/f856d8e8e7eeee228ce44bfdf021a6735ad2ebbe..7dad4b118fe1debab178df8df629bde20b5233fa Florin, could this be https://chromium.googlesource.com/chromium/src/+/d1d05d02de7519c777358ce926c007a7222449d6 ? (Feel free to reassign if not.)
,
Sep 15
That CL introduced the "small" (close to 1) scale factor that seems to be required to trigger this issue. It seems more likely that it merely exposed a bug elsewhere though (seeing that the bug is with GPU raster [and stroke].)
,
Sep 18
,
Sep 18
,
Sep 18
fs is right: that small scale adjustment must be tickling a Ganesh bug. E.g. https://fiddle.skia.org/c/f833104e6c715a8ca2dc7b92a475b7a6 |
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by meh...@chromium.org
, Sep 13