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

Re: Towards Better Anti-aliasing

From: Rik Cabanier <cabanier@gmail.com>
Date: Tue, 1 Nov 2011 17:39:29 -0700
Message-ID: <CAGN7qDBJd6JvznW6+TiT2mo4zgsPzyEx01jQfGOu0Z7+B=1LdA@mail.gmail.com>
To: Mike Bostock <mbostock@cs.stanford.edu>
Cc: Cameron McCormack <cam@mcc.id.au>, www-svg@w3.org
>
>
>
> > I'm doubtful that FSAA will be an acceptable solution since it will
> apply to
> > the whole destination image. You usually want different rules for images,
> > line art and text.
>
> I disagree; FSAA is exactly the sort of thing that you'd want on the
> entire destination image. I can't think of any situation where you
> wouldn't want FSAA (if it were supported by the implementation, and
> had zero or positive performance implications). The results of FSAA
> will either be equivalent or more correct than rasterizing shapes
> independently. It doesn't make much sense to enable FSAA for some
> shapes but not others, since FSAA requires a completely different
> graphics pipeline.
>
> Instead, I see FSAA as the sort of thing you get for free if the
> implementation is designed from the beginning to support it. (You
> could still use crispEdges for individual shapes.)
>

Hi Mike,

I thought about this some more and talked to people that implemented the
GPU acceleration of Acrobat.
FSAA is indeed a viable solution to do anti-aliasing.
However, the implementation needs to be really careful where it places
images and how it renders text so that they are not affected by the AA
algorithm.

Rendering paths and strokes on the GPU is not a trivial task. Some of your
problems stem from very thin paths and because the GPU uses centerscan, you
will see incorrect results.
Maybe you could just render your svg to twice the resolution and then
downsample it...

Rik
Received on Wednesday, 2 November 2011 06:14:54 GMT

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