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

Re: Towards Better Anti-aliasing

From: Rik Cabanier <cabanier@gmail.com>
Date: Mon, 31 Oct 2011 21:15:49 -0700
Message-ID: <CAGN7qDAN8_7rPZRrquzQO9+2dXdHoSYPTs0qZRcfmqp+Ww4pdA@mail.gmail.com>
To: Cameron McCormack <cam@mcc.id.au>
Cc: www-svg@w3.org, mbostock@cs.stanford.edu
Hi Cameron,
shared edges should be able to help somewhat. The SVG viewer will need to
process them as one chunk and the author would have to express overlapping
artwork with them.
(Shared edges are what flash player uses as well. They speed up software
rendering and make antialiasing easier)
It looks like Mike's examples would be fixed if 'shape-rendering' was set
to 'crisp-edges'.

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.


On Mon, Oct 31, 2011 at 11:53 AM, Cameron McCormack <cam@mcc.id.au> wrote:

> On 31/10/11 11:44 AM, Rik Cabanier wrote:
>> 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<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.
> We did accept a requirement for SVG2 to improve the situation with seams
> between elements.  I wonder whether the super path proposal (or whatever
> solution we end up with for shared path edges) can help here, so that the
> implementation can be aware of what paths will result in full coverage of
> particular pixels.  I am not sure we want to go down the path of requiring
> FSAA with particular properties like shape-rendering -- if implementations
> are hardware accelerated and want to enable FSAA then I think they should
> just be able to.
Received on Tuesday, 1 November 2011 05:17:27 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:54:33 UTC