[whatwg] Antialiasing of line widths < 1 (was Re: Blurry lines in 2D Canvas (and SVG))
senorblanco at chromium.org
Tue Aug 13 08:51:49 PDT 2013
On Sat, Aug 10, 2013 at 11:07 PM, Rik Cabanier <cabanier at gmail.com> wrote:
> On Sat, Aug 10, 2013 at 7:50 AM, Glenn Maynard <glenn at zewt.org> wrote:
>> On Sat, Aug 10, 2013 at 7:42 AM, Stephen White <senorblanco at chromium.org>wrote:
>>> Chrome (well, Skia actually) uses a "hairline" mode for line widths < 1.
>>> It draws a line of width 1, and uses the width to modulate the alpha. I
>>> think the idea is to prevent blotchiness/unevenness caused by undersampling
>>> or missed coverage (Skia uses 16 samples of AA).
>> That sounds like it should be fine, since it should give results similar
>> to what users would expect from simple coverage antialiasing.
>> I'm not sure that's what I'm seeing, though.
>> http://jsfiddle.net/eZEyH/1/ The 0.001 width stroke is being drawn
>> solid black in the pixel-centered (left) case. In the right one,
>> horizontally aligned to the edge of a pixel, the stroke disappears. (I
>> left it vertically pixel-centered, so the box didn't disappear entirely.)
>> The right is what I'd expect to always happen with a lineWidth that thin.
>> Similar things happen with thicker widths, the 0.001 just makes it very
>> easy to see.
That is clearly a bug. :-)
Yep, seems to be a bug in Skia's raster backend. I've logged it as
https://code.google.com/p/skia/issues/detail?id=1505; feel free to add
further comments there.
>> This can become visible during animation, eg.
>> http://jsfiddle.net/xSUuB/1/. In Chrome, the line flickers between
>> solid black and grey. In Firefox, it's antialiased normally, so it
>> consistently appears grey (actually shifting between one pixel of grey and
>> two pixels of lighter grey).
> Yeah. Chrome seems to flip between no AA and AA which sounds like a bug in
> their algorithm.
More information about the whatwg