- From: Rik Cabanier <cabanier@gmail.com>
- Date: Tue, 1 Nov 2011 17:39:29 -0700
- To: Mike Bostock <mbostock@cs.stanford.edu>
- Cc: Cameron McCormack <cam@mcc.id.au>, www-svg@w3.org
- Message-ID: <CAGN7qDBJd6JvznW6+TiT2mo4zgsPzyEx01jQfGOu0Z7+B=1LdA@mail.gmail.com>
> > > > > 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 UTC