W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2013

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

From: Glenn Maynard <glenn@zewt.org>
Date: Fri, 9 Aug 2013 22:12:49 -0500
Message-ID: <CABirCh_0orFzaZAUrtg3Z+Jg0LdSGMZxuapVdKZgigEdKJJVXQ@mail.gmail.com>
To: Rik Cabanier <cabanier@gmail.com>
Cc: WHAT Working Group <whatwg@whatwg.org>, bdahl@mozilla.com, Stephen White <senorblanco@chromium.org>, w3c@junglecode.net
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.

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

-- 
Glenn Maynard
Received on Saturday, 10 August 2013 03:13:13 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:23 UTC