Is this just a duplicate of issue 631508, "antialiasing makes rounded borders look bad"?

There might of course be a common underlying cause, but there seem to be two different issues: 631508 is about the poor arc drawing. This one is about an artifact at the junction between the arc and the straight line.


By the way, I was wrong about the border being supposed to be a perfect circle (wasn't taking into account that the radius is the outer one, so there's an extra pixel), but the issue about the junctions still holds.

I'll need to look at this on a machine where I can see individual pixels when zoomed, but it is the case that when drawing a circle using minimum error methods into a raster backing, you get straight sections on the sides that do not look dissimilar to the image given. It's just the way it is trying to draw a continuous thing on discrete pixels.

I'd be curious what an SVG circle the same size looks like? I know it won't be exactly the same because we use bezier arc approximations for border corners.

> I'll need to look at this on a machine where I can see individual pixels 
> when zoomed

Or you can take a screen capture and zoom it in an image viewer or editor ;)

> but it is the case that when drawing a circle using minimum error methods 
> into a raster backing, you get straight sections on the sides

Forget about the straight sections within the arcs, that's issue 631508 (they shouldn't exist, no matter what, but I don't really observe them in this test case).


The issue here is the artifacts at the point where the the arc begins and ends, and joins with the (expected) straight part of the border (the part that is not a rounded corner).

Here's a less confusing test case:
http://jsbin.com/fuyujuh/edit?html,css,output

Deleted: xxx.png 3.4 KB

	xxx.png 3.4 KB View Download

Deleted: zoomed.png 3.1 KB

	zoomed.png 3.1 KB View Download

What you are seeing is the transition from the straight initial curve segment to the first pixel that is off the straight segment. In other words, part of the border radius curve is straight and exactly aligned with the straight part of the border, as expected.

Please somebody not retarded review this

@schenney try to draw the exact same shape with any vector drawing software and you'll see that the junction can be rendered better.

That is NOT the expected result, you can clearly notice eight "dots", where the line looks thicker, there's no reason for that. It's poorly rendered, period.

Indeed, the problem seems to be that the ending of the curve and the straight line are NOT exactly alligned (as they should be). The curve seems to be drawn "one pixel inwards"

Re comment #8, see https://www.chromium.org/conduct

The ending of the curve and the straight line are exactly aligned. You can identify where the straight segment ends and where the curve segment begins and at that point the curve is continuous. Your complaint is with the anti-aliasing artifacts of the curve drawing, and that is a valid concern.

However, Chrome is not vector drawing software, it is a web browser that must trade off performance against visual fidelity across a very high range of devices and content. The bug is WontFix because we will not devote resources to improving this particular rendering.

>  Your complaint is with the anti-aliasing artifacts of the curve drawing, 
> and that is a valid concern.

Ok now we are talking. You started comment 7 with "what you are seeing is..." and ended with "as expected", which seemed to imply that this was the expected behavior.


> The bug is WontFix because we will not devote resources to improving 
> this particular rendering.

So for you it is acceptable that the rendering of all rounded-corner rectangles is just broken??
Unbelievable.

Oh, but Firefox does it even worse, so I guess it's ok.

> it is a web browser that must trade off performance against visual fidelity

I'm pretty sure a decent result can be obtained without compromising performance.

I guess this could be something like https://bugs.chromium.org/p/skia/issues/detail?id=5017 (i.e number of gray-levels used by the rasterizer.) If this is most notable for 1px borders, I'd also suspect hairline rendering, but some quick testing didn't seem to indicate that.

"totally broken" is certainly an exaggeration, but there's a case to be made for improved AA.

I think at least part of it is related to (the current lack of) color space correction: Skia interpolates in linear space, but the result is dumped to a non-linear device without correction - so 50% black coverage for example doesn't translate to 50% gray, visually.

Luckily there are people working on color correction in Skia as I type this, so as soon as Chromium starts to take advantage of it things should get better.

E.g. see the attached examples (columns are CPU vs. GPU rendering, PNGs are linear/uncorrected vs. SRGB/corrected).

Deleted: aa_linear.png 4.0 KB

	aa_linear.png 4.0 KB View Download

Deleted: aa_srgb.png 4.9 KB

	aa_srgb.png 4.9 KB View Download

> E.g. see the attached examples (columns are CPU vs. GPU rendering, 
> PNGs are linear/uncorrected vs. SRGB/corrected).

Which one is supposed to demonstrate an improvement? Both sides of aa_srgb.png are broken (the curves being systematically thinner/lighter than the straight lines). 

Of the "linear" ones, the one on the left  looks pretty much like the current behavior. The one on the right (GPU?) has the curves noticeably thicker than the straight lines (given that, it's hard to tell whether it also has the artifact at the junction, or if it is the result of the transition from a thinner to a thicker line).


I am genuinely surprised to see this stuff. I understand that the problem of correctly drawing and antialiasing a 1-pixel-thick line (or a line of any width for that matter), with straight and curved portions and no discontinuities (or with them, for that matter), is a complex one. But hasn't it already been solved like decades ago?

> Which one is supposed to demonstrate an improvement? Both sides of aa_srgb.png are broken (the curves being systematically thinner/lighter than the straight lines). 

You are looking at the unscaled image (open in a separate tab), and not the scaled-down version above, right?

> You are looking at the unscaled image (open in a separate tab), 
> and not the scaled-down version above, right?

Of course! 

And then (for the sake of curiosity) I am also looking at the images in GIMPP zoomed in by multiples of 200% (without any kind of interpolation).

And you think aa_srgb.png looks bad at native rez?  I gotta admit that sounded crazy, but come to think of it it's not all that surprising.

For the record, on my IPS monitor aa_srgb.png looks as good as I could ever expect (and much better than aa_linear.png, which as you've noticed is what we currently output).

But moving the tab to a TFT monitor, it does get slightly worse.  By now you may have figured where this is going.

Essentially, it's impossible to have "perfect" AA without full monitor color matching.  Back to my prev example, 50% black coverage needs to show up exactly midway between your monitor's black and white.  But that's totally dependent on your monitor's color gamut!

I've rendered that image assuming an SRGB profile, so if your monitor is not SRGB (or deviates from it somehow), it'll not look as good.  You could try different displays, and see if it makes a difference.