New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 847080 link

Starred by 1 user

Issue metadata

Status: Duplicate
Merged: issue 828925
Owner:
Closed: Jun 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows , Mac
Pri: 1
Type: Bug



Sign in to add a comment

Occasional SVG polygon fill glitch

Reported by monfera....@gmail.com, May 27 2018

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.181 Safari/537.36

Steps to reproduce the problem:
1. Go to https://codepen.io/monfera/pen/RyXmjL
2. Observe that, every few seconds, the gray painted area is suddenly enlarged (for me, it's happening on the right hand side), as if it tried to encircle all points on the right
3. 

What is the expected behavior?
Although it's quite a bit of stress testing in terms of polygon self-intersections, I believe it shouldn't yield these blinks.  I see blinking at as low as `var n = 500` (see the first JS row) but, since the rAF loop is faster, the blink is more transient, harder to notice. Setting `fill-opacity` of the `polyline` to 1 in CSS makes the blinking more prominent.

What went wrong?
See the attached MP4: blinking is prominent on my machine(TM)

Did this work before? Yes I don't know, but I didn't notice it when creating it the original of this fork maybe a couple of years back

Does this work in other browsers? No
 The issue is present in Safari.
FireFox doesn't have this glitch.

Chrome version: 66.0.3359.181  Channel: stable
OS Version: OS X 10.13.4
Flash Version: 

Probably completely unrelated to https://bugs.chromium.org/p/chromium/issues/detail?id=844998
 
blink.mp4
9.2 MB View Download
Blinking seems to need `shape-rendering: optimizeSpeed;`. I simplified the codepen and the glitch is not present in Safari anymore, just in Chrome.
Labels: Needs-Bisect
Labels: Needs-Triage-M66
Cc: sindhu.chelamcherla@chromium.org
Labels: -Pri-2 -Needs-Bisect hasbisect-per-revision Target-67 RegressedIn-61 M-68 Target-66 FoundIn-66 FoundIn-67 Triaged-ET FoundIn-68 Target-68 OS-Windows Pri-1
Owner: senorblanco@chromium.org
Status: Assigned (was: Unconfirmed)
Able to reproduce this issue on reported version 66.0.3359.181 and latest canary 69.0.3443.0 using Windows 10 and Mac 10.13.3. Issue is not seen in Ubuntu 14.04.

Good Build: 61.0.3123.0 
Bad Build: 61.0.3124.0 

You are probably looking for a change made after 477557 (known good), but no later than 477558 (first known bad).
CHANGELOG URL:
 https://chromium.googlesource.com/chromium/src/+log/6dacd834a9f5bd10f3de9e4780b4d48064370f95..25808b7ff3e61f9951ab104d7148f31e0820f0fb

Suspecting https://skia.googlesource.com/skia.git/+/3b5a3fa8b1c11d4bd4499b040311f4c3553ebf8c from skia roll.

@ senorblanco: Please confirm the bug and help in re-assigning if this is not related to your change.

Thanks!

Comment 5 by f...@opera.com, May 28 2018

Components: Internals>GPU>Rasterization
Components: -Blink>SVG
Labels: -Type-Bug-Regression Type-Bug
Things that broke back in M-61 are not P1 regressions.
This seems to be fixed in ToT. bisecting for the fix yields:

You are probably looking for a change made after 563708 (known bad), but no later than 563719 (first known good).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/64deab5ecc66665d1404fb79b408d8519669efca..aa14a6793133f867d63bb3154866c8ae1dfe8c6a

Suspecting 531a48ed788c5fabfe21704286b54d7567f35469 from the Skia roll fixed it.
Mergedinto: 828925
Status: Duplicate (was: Assigned)
Indeed, reverting 531a48ed788c5fabfe21704286b54d7567f35469 brings the bug back. Marking as fixed.

Sign in to add a comment