Re: Towards Better Anti-aliasing

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.

Rik

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.
>