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

Glenn Maynard glenn at zewt.org
Fri Jul 26 07:45:20 PDT 2013

On Thu, Jul 25, 2013 at 10:29 PM, Rik Cabanier <cabanier at gmail.com> wrote:

> We're getting a bit off track here :-)

We're figuring out an unclear use case.  That's as on-track as it gets.  :)

> No, you need to scale, otherwise the content of your canvas won't scale
> up.
> For instance, if you have a 100x100 device pixel rect, it has to become a
> 110x110 device pixel rect if you zoom by 10%

Okay, that wasn't clear to me.  Pixel ratios are peripheral to what you're
describing: you could ask for the same thing any time you're rendering to a
dynamically-sized canvas, which simplifies the discussion.  I don't know if
a complex semi-antialiasing mode is a good approach, though.  It'll always
have issues (rounded corners won't "connect" cleanly; it's not clear if it
works for fills, or if it works for patterned fills).

I don't know if this would work well in practice, or if it's implementable,
but here's a two-part approach that might work:

- First, add the inner and/or outer stroke modes.  This seems useful in and
of itself, but the purpose here is to make it so integer coordinates give
hard edges, whether or not you have a 1px stroke.
- Second, add a mode which causes coordinates to be snapped to integers.
 This would happen when you make the API call, and be applied after the
canvas transform.

If you're in scale(1.25), and you call rect(100, 100, 75, 75), it would
draw a rect from 100x100 to 194x194, instead of to 193.75x193.75.

This would give clean output for rounded edges, since you're adjusting the
size of the path as a whole.  It would work for fills (which also get
aliased edges when transformed).  It also works if the fill is a pattern,
where turning off antialiasing would make the pattern ugly.

Glenn Maynard

More information about the whatwg mailing list