Re: Towards Better Anti-aliasing

I think our goal should be to make the pitfalls of antialiasing more
visible, both to users (so they know what they're missing) and to
implementors. Implementors should be aware of the trade-offs of
different antialiasing approaches, rather than simply picking the one
that is most convenient to implement.

I don't think that any changes in the spec are necessary, but I would
like to see language that recommends a particular approach, if
feasible. The ideal implementation would push as much of the geometry
onto the graphics card as possible, and then simply enable
GL_MULTISAMPLE or equivalent for beautiful full-scene anti-aliasing.

My guess is that implementations don't do this currently because they
are built on an intermediate layer with immediate mode graphics, such
as Skia, where each graphical primitive is rasterized separately. This
is appropriate for Canvas, but SVG's declarative scenegraph should
lend itself better to hardware acceleration and thus FSAA.

Although useful for other things (particularly cartography) I don't
see shared edges as helping here. For example, in hierarchical edge
bundling, the splines do not have shared edges but they do share
pixels. Similarly, shape-rendering: crispEdges is undesirable because
that turns off anti-aliasing completely. (And that doesn't always work
as expected: sometimes .5px-wide lines are rendered as 2px.)

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

If I have time, I'd like to prototype a JavaScript shim that renders
SVG to WebGL to see how difficult it is. Obviously, I'd start with a
very limited subset, such as rects. :) I expect that certain things
(such as filters, masking, pattern fills) may be more difficult to
support without an intermediate immediate-mode graphics layer.

Mike

Received on Tuesday, 1 November 2011 18:14:37 UTC