[whatwg] Blurry lines in 2D Canvas

[Ruben Rodriguez II]

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 
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#image-smoothing 
... 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?
>