User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:76.0) Gecko/20100101 Firefox/76.0

Steps to reproduce:

Open this SVG file (which is a minimal reproduction):

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" height="50"><circle cx="0" cy="12" fill="lime" stroke="red" stroke-width="2" r="11"/></svg>

Actual results:

When the SVG element is 25, 27, 50, 51, 53 or 54 pixels high, the stroke of the circle is misrendered as depicted in the attached screenshot. I’m using a display with a scaling factor of 200%, so those pixel sizes could be different on a 100% display.

Expected results:

The stroke should have been so very beautifully rounded that Pythagoras and Euler could have found no fault with its proportions.

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Thanks for the bug report! I can reproduce in Linux Nightly if I manually enable WebRender (by setting gfx.webrender.all to true). And I assume Chris's Windows environment is one that we've deemed suitable for enabling WebRender by default, which is why he sees it without needing any pref-flips (presumably).

Chris, as an extra sanity-check, would you mind visiting about:config and setting gfx.webrender.force-disabled to true, and seeing if that fixes the issue for you (after you restart Firefox)?

regression window, unfortunately a full day, builds for intermediate changesets I guess have expired
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=0a71d114c5e223542ca6687bbdf3ecb16c380677&tochange=afa70e5e516abf11f4760b915c0b3d09bc351147

archive.mozilla.org has slightly more builds available then mozregression apparently (two nightlies a day vs one?) (wish mozregression could find them). Narrow range to

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=9ee54a21a22ab5beab264bcabe3c8039a27a32e8&tochange=afa70e5e516abf11f4760b915c0b3d09bc351147

which I think implicates bug 1494408

I actually opted into WebRender manually very early on, though I flipped back and forth a few times on occasions when it caused actual problems. Either way it seems to be enabled now without needing any forcing. Anyway, WebRender does seem an almost certain culprit for this sort of thing, and the checking you guys have done seems to confirm it, and I’m too lazy right to switch back and restart my browser a couple of times, so can we take that as given?

Such a fascinatingly specific bug. I can easily see how it could have surfaced two years ago without anyone noticing since then; I only got it because I was manually constructing an SVG icon and it was at just the right size to trigger the bug!

Nical - can you take a look?

It looks like this is just a skia bug. I was able to reproduce it using regular canvas without webrender.

The same problem shows up in Chrome if you disable gpu accelerated canvas.

I filed a Chrome issue: https://bugs.chromium.org/p/chromium/issues/detail?id=1070835. We might as well wait to see where that goes.

The component has been changed since the backlog priority was decided, so we're resetting it.
For more information, please visit auto_nag documentation.

This has been fixed in Skia: https://skia.googlesource.com/skia.git/+/1ae3e75a0b4ca698e18e7991d151dc17630f4acb%5E%21/#F1

What do want to do here Lee?

(In reply to Jeff Muizelaar [:jrmuizel] from comment #12)

This has been fixed in Skia: https://skia.googlesource.com/skia.git/+/1ae3e75a0b4ca698e18e7991d151dc17630f4acb%5E%21/#F1

What do want to do here Lee?

It might be best to just wait to pick this up when we next update Skia, if that is acceptable?

(In reply to Lee Salzman [:lsalzman] from comment #13)

(In reply to Jeff Muizelaar [:jrmuizel] from comment #12)

This has been fixed in Skia: https://skia.googlesource.com/skia.git/+/1ae3e75a0b4ca698e18e7991d151dc17630f4acb%5E%21/#F1

What do want to do here Lee?

It might be best to just wait to pick this up when we next update Skia, if that is acceptable?

Do you have an idea of what time frame that will be?

(In reply to Jeff Muizelaar [:jrmuizel] from comment #14)

(In reply to Lee Salzman [:lsalzman] from comment #13)

(In reply to Jeff Muizelaar [:jrmuizel] from comment #12)

This has been fixed in Skia: https://skia.googlesource.com/skia.git/+/1ae3e75a0b4ca698e18e7991d151dc17630f4acb%5E%21/#F1

What do want to do here Lee?

It might be best to just wait to pick this up when we next update Skia, if that is acceptable?

Do you have an idea of what time frame that will be?

Possible next month or later. They are probably a couple weeks out from cutting a new milestone which would include that fix.

It looks like the bug has been around for since at least 2017-01-01 so I think we can probably wait a little longer.

Yeah, this is a super niche bug, that I just happened to find because the icon I was crafting was just right to trigger it. Waiting for the next routine Skia update sounds wise to me.

Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is P3 (Backlog,) indicating it has been triaged, the bug's Severity is being updated to S3 (normal.)