Re: [whatwg] Antialiasing of line widths < 1 (was Re: Blurry lines in 2D Canvas (and SVG))

On Sat, Aug 10, 2013 at 11:07 PM, Rik Cabanier <cabanier@gmail.com> wrote:

>
>
> On Sat, Aug 10, 2013 at 7:50 AM, Glenn Maynard <glenn@zewt.org> wrote:
>
>> On Sat, Aug 10, 2013 at 7:42 AM, Stephen White <senorblanco@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.

Stephen

>
>
>>
>> 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.
>

Received on Tuesday, 13 August 2013 15:52:14 UTC