W3C home > Mailing lists > Public > www-svg@w3.org > October 2011

Re: Towards Better Anti-aliasing

From: Rik Cabanier <cabanier@gmail.com>
Date: Mon, 31 Oct 2011 11:44:31 -0700
Message-ID: <CAGN7qDBdRoYeL7Ner=muRVmYT3hCDsn6pR0Ubvc8xM55d_RpEQ@mail.gmail.com>
To: Mike Bostock <mbostock@cs.stanford.edu>
Cc: www-svg@w3.org
Hi Mike,

do you consider these bugs in the browser or do you want to see the SVG
spec specify better how things should be rendered?
The spec already defines some keywords to address your issue. See
shape-rendering in http://www.w3.org/1999/07/06/WD-SVG-19990706/render.html
Some browsers also have the crisp edges keyword to turn off antialiasing on
the entire SVG file.

Rik

On Fri, Oct 28, 2011 at 11:20 AM, Mike Bostock <mbostock@cs.stanford.edu>wrote:

> At SVG Open I raised the issue that current anti-aliasing
> implementations are woefully inadequate and lead to a variety of
> visual artifacts. The general issue is that these implementations
> anti-alias each shape individually against a canvas, rather than using
> some form of full-scene anti-aliasing, such as supersampling or
> multisampling [1].
>
> Here's an example where subpixel rects completely fill a region, but
> because each rect is anti-aliased individually, the background bleeds
> through:
>
>  http://bl.ocks.org/1322907
>
> This is also apparent in Polymaps when displaying tiles at non-integer
> zoom levels because the tiles are at subpixel positions:
>
>  http://polymaps.org/ex/pale-dawn.html#11.62/37.7159/-122.9085
>
> Notice the horizontal and vertical lines where the background bleeds
> through. The effect is a bit more apparent on Firefox than on Chrome.
> In fact, Firefox shows this artifact even at integer zoom levels,
> because the containing SVG itself uses subpixel positioning! If you
> change the width of the window, you'll see the vertical lines flicker
> based on whether the window is an even or odd number of pixels wide.
>
> Another case is multiple thin coincident shapes. The shapes are
> anti-aliased separately, each time blending the new shape against the
> current accumulation; eventually, this causes the opacity of any pixel
> that touches any part of the lines to reach opacity 1, which is
> equivalent to having no anti-aliasing at all! Here are 400 coincident,
> opaque diagonal lines. They should appear identical to one opaque
> diagonal line:
>
>  http://bl.ocks.org/1322948
>
> Also notice the jaggies on the blue edges coming out of the NodeSprite
> and related classes:
>
>  http://bl.ocks.org/1044242
>
> I've attached an image which magnifies the artifact.
>
> I filed a bug against WebKit requesting this in early 2010:
>
>  https://bugs.webkit.org/show_bug.cgi?id=35211
>
> I think it would be reasonable to omit this feature in software
> implementations, but as we move increasingly to GPU-based rendering
> this feature would greatly improve rendering quality for complex
> images. The only SVG implementation I am aware that uses full-scene
> antialiasing is Anti-Grain Geometry:
>
>  http://www.antigrain.com/svg/index.html
>
> Mike
>
> [1] http://en.wikipedia.org/wiki/Multisample_anti-aliasing
>
Received on Monday, 31 October 2011 18:45:20 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:49 GMT