[whatwg] Blurry lines in 2D Canvas

Ruben Rodriguez II whatwg at therealcha0s.net
Fri Sep 27 14:21:20 PDT 2013

I would just like to note that sometimes we do not WANT to draw precise 
shapes. :) Many people enjoy the aesthetic of 2d pixel-based graphics, 
and it should be a viable choice for the graphical style of a game, for 
instance. Canvas makes this more difficult, and it shouldn't be so!

Why can't we have a global option to turn this off if we want to? I'm 
not trying to advocate for throwing away all antialiasing... I 
understand that most applications will probably want it by default, and 
agree with having it as the default.

Basically all it is is 
... except that we're not talking about scaling.

On 09/05/2013 05:22 PM, Ian Hickson wrote:
> On Tue, 23 Jul 2013, Rik Cabanier wrote:
>> we've noticed that if you draw lines in canvas or SVG, they always end
>> up blurry. For instance see this fiddle: http://jsfiddle.net/V92Gn/128/
> Not always, only if you don't draw the line aligned with the pixel grid
> (e.g. you draw a diagonal line, or a horizontal or vertical line that
> isn't centered in the middle of pixels on the pixels grid, or a horizontal
> or vertical line whose width isn't an integral number of pixels, etc).
> The options, on a pixel grid display, are:
>   - don't honour the position precisely -- this leads to very ugly
>     artifacts when animating (lines jerk around), and basically means that
>     the graphics aren't accurate.
>   - instead of describing the shapes as vectors, describe them using
>     programs that can adapt to the position and size they're being drawn
>     at, such that they automatically snap to the pixel grid in a pretty
>     fashion -- this is what fonts do.
>   - try to trick the eye by using anti-aliasing when things don't line up
>     exactly on the pixel grid.
> The first two really aren't plausible options for <canvas>.
> On Wed, 24 Jul 2013, Kornel Lesiński wrote:
>> For 1-pixel lines it could be fixed by allowing authors to specify that
>> path should be stroked with lines aligned to inside/outside of the path
>> (which is a useful feature on its own).
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=22674
> On Tue, 23 Jul 2013, Rik Cabanier wrote:
>> Sure, but how can we fix this?
> What is there to fix? The options above are basically the only options.
> You can't not do one of them -- there's no way to draw a crisp line that
> isn't pixel aligned. There's no pixels there. Similarly, there's no way to
> draw a line that's neither horizontal nor vertical yet is crisp and
> doesn't look jaggy. The pixels are squares, they don't rotate on modern
> pixel displays.
> On Wed, 24 Jul 2013, Kornel Lesiński wrote:
>> Should arc() and bezier curves also be snapped? What if you want a line
>> that touches the curve?
> That's precisely the problem with snapping -- it is far worse than
> antialiasing. You can't draw precise shapes if you have snapping.
> On Wed, 24 Jul 2013, Dirk Schulze wrote:
>> Means implementations would need to take viewport, transformations of
>> the document, transformations on elements in the DOM hierarchy, zoom
>> level, aspect ratio of the canvas, position of the canvas in the
>> document, transformations in the canvas and device pixel resolution into
>> account to snap lines to the correct position on the individual device,
>> right?Otherwise it sounds to be hard to guarantee that you don't see
>> antialiased strokes and lines might snap more then just one device
>> pixel. This would also be a problem for aligning shapes to each other in
>> the canvas I guess. What happens on the next transformation after a
>> drawing operation. Say you draw a line that was snapped to the grid and
>> then you do scale(1.1, 1.1). Shall the implementation redraw the canvas?
>> After all it is an pixel image. A vector based drawing format would be
>> better suited for such a task.
> Indeed.
> On Sat, 10 Aug 2013, Rik Cabanier wrote:
>> I was wondering if this is something that happens in Flash as well. It
>> turns out that there's an option called "hinting: Keep stroke anchors on
>> full pixels to prevent blurry lines." There's a blog post on what this
>> does:
>> http://www.kaourantin.net/2005/08/stroke-hinting-in-flash-player-8-aka.html
>> <http://www.kaourantin.net/2005/08/stroke-hinting-in-flash-player-8-aka.html>
>> I created an example (in flash sorry) that shows the feature:
>> http://cabanier.github.io/BlendExamples/pixelsnap/pixelsnap.html
>> 2 sets of strokes move across the screen and are also scaled.
>> The top strokes behave like canvas does today. They start of blurry and
>> during the animation they slowly get ticker. For some reason it doesn't
>> look very smooth.
>> The bottom strokes have hinting turned on. They are sharp at the beginning
>> and during the animation they stay the same size until the internal stroke
>> width is large enough. At that point you see a 'jump'.
>> I think canvas should have a similar feature...
> Can you elaborate on how exactly you would want this to work? How would
> you avoid the alignment and distortion problems when applying this to
> anything less trivial than a rectangle?

More information about the whatwg mailing list