Re: [whatwg] Blurry lines in 2D Canvas (and SVG)

On Fri, Aug 9, 2013 at 8:12 PM, Glenn Maynard <glenn@zewt.org> wrote:

> On Fri, Aug 9, 2013 at 7:16 PM, Rik Cabanier <cabanier@gmail.com> wrote:
>
>> In addition if
>> the corners of the path don't align with the grid, you will get a blurry
>> outline again.
>>
>
> That's the purpose of the second half of my proposal: snapping coordinates
> and line widths to integers.
>
> As an experiment, I drew 4 rectangles in JSFiddle with stroke width of .5,
>> .75, 1, 1.5 and 2: http://jsfiddle.net/6KS4V/2/
>> I aligned them to the grid as Glenn suggested.
>> This is a blown up screenshot from IE (Firefox looked the same):
>> http://bit.ly/16FVCKd
>> and here's one from Chrome: http://bit.ly/19Tf9Ko
>>
>> The rectangle that's 2 points wide is somewhat blurry, but the one that is
>> 1.5  is very bad.
>>
>
> Right.  In case anyone's not following, this is what's happening:
> https://zewt.org/~glenn/stroke-alignment.png  The red box is the
> rectangle being drawn.  The blue lines are the actual strokes.  (This was
> created by hand, it's not an actual Canvas rendering.)
>
> The top row is drawing with integer coordinates.  With a 1px stroke, the
> stroke sits across two pixels, so it aliases.  With a 2px stroke, it fully
> covers two pixels and doesn't alias.  With a 3px stroke, it aliases again.
>
> The middle row is drawing with half-coordinates.  The pattern is reversed:
> clean, aliased, clean.  Additionally, fills (with no stroke) always
> aliases, since the red box lies between pixels.
>

How would you fix a 1.5 pixel width for the stroke or a 1.5 transform?


>
> The bottom row is an outer stroke and integer coordinates: neither strokes
> nor fills alias, in all three cases.  This is the mode I'm suggesting.
>
> Chrome seems ignore stroke widths that are smaller than 1 (which is
>> reasonable).
>>
>
> (That seems wrong to me--it should continue to draw based on pixel
> coverage--but that's a separate issue...)
>

Is it? Obviously you can't draw less than a pixel, but the user did specify
that he wants it too look black.
I admit that this is not a clear cut problem. Our applications also have
different ways of rendering depending on what the user is trying to
accomplish.
If the intent is to mimic high resolution printed output, we blur the lines
like Canvas and SVG currently do.
If the screen is considered the output device (like  in Acrobat), we snap
the line art because it looks better (ie grids for spreadsheets). This is
most likely why CSS snaps too.

Received on Saturday, 10 August 2013 04:07:38 UTC