WebKit's current implementation of SVG appears to antialias shapes individually as they are drawn. Although this produces adequate results in simple SVG images, it quickly introduces jaggies and bleeding when an image has many shapes with subpixel positions. To eliminate these artifacts, full-scene antialiasing (FSAA) is needed (e.g., GL_MULTISAMPLE in OpenGL). FSAA avoids background color bleeding between contiguous shapes. The referenced URL shows a simple example of background color bleeding. Four hundred 1/2-pixel wide <rect> elements are drawn adjacent. These rects are opaque, and the text underneath should not be visible. (The text would be hidden if shape-rendering="crispEdges".) However, since the rects are individually antialiased, they are drawn partially transparent.
What section of the SVG 1.1 or 1.2 spec covers this?
Antialiasing is not a requirement of the spec (at least, as of 1.1). So whether the antialiasing should be full-scene is not a formal requirement, either, but a practical necessity for high-quality rendering. Specifically the spec says in section G.7: """ Although anti-aliasing support is not a strict requirement for a Conforming SVG Viewer, it is highly recommended for display devices. Lack of anti-aliasing support will generally result in poor results on display devices. """
I'm not sure how you do FSAA with a graphics library like CoreGraphics: http://developer.apple.com/mac/library/documentation/GraphicsImaging/Conceptual/drawingwithquartz2d/Introduction/Introduction.html Maybe you draw the whole scene non-antialiased and then have some anitaliasing pass? Despite having written much of our SVG implementation, I really know very little about graphics. If someone would like to point me towards the right approach/calls in CG or Skia or Cairo, or any other 2d graphics library, I could comment more on the feasibility of wiring this into our SVG implementation. How does FSAA interact with repaint? Are 2d drawing APIs expected to maintain some sort of scenegraph under the covers in order to remember the paint order? (Maybe that doesn't matter for antialiasing?) How would we expose something like this to <canvas> Wouldn't it want a way to do FSAA as well?
Disclaimer: while I know some 3D graphics, I don't know as much as I should about how multisample antialiasing works. My understanding is that when doing full-scene antialiasing via multisampling, the graphics card maintains multiple samples per pixel, specifically of triangles which overlap that pixel. When the rendered output is to be drawn to the screen, the multiple samples are resolved (averaged?) down into a single color per pixel. The algorithms used to accumulate the samples guarantee that even if two adjacent shapes share antialiased edges, there will be no bleed-through of the content behind those edges. In order for SVG to take advantage of this technique, a graphics API like OpenGL which supports FSAA would need to be used to draw all of the shapes. 2D Canvas would be able to take advantage of the technique as well if it were changed to draw using OpenGL.
What Eric describes is supersampling: just rendering at a higher res and downsampling. Its cost is pretty much the square of the linear increase in size (ie. 2X supersampling = 4X time). This could be done transparently in most graphics libraries (i.e., they don't have to support it). But it is slow. Multisampling (as in OpenGL) has the advantage that it only runs the per-pixel operations (e.g., texturing) once. So its cost is lower than supersampling. And of course, there are hardware implementations. However, it does have artifacts, especially with transparency (in the straight MSAA version). Also, although most desktop graphics cards support it, it isn't required by the OpenGL spec, and AFAIK many mobile chips do not. Anyway, all that to say, it would be nice to support it, but it will come at a performance cost, especially for software implementations.
(In reply to comment #5) > What Eric describes is supersampling: just rendering at a higher res and downsampling. Its cost is pretty much the square of the linear increase in size (ie. 2X supersampling = 4X time). This could be done transparently in most graphics libraries (i.e., they don't have to support it). But it is slow. Whoops, that's wrong. 2X means 2 samples, not 4, so 2X time. 4X samples, 4X time. So linear in the number of samples (approximately). > Multisampling (as in OpenGL) has the advantage that it only runs the per-pixel operations (e.g., texturing) once. So its cost is lower than supersampling. And of course, there are hardware implementations. However, it does have artifacts, especially with transparency (in the straight MSAA version). Also, although most desktop graphics cards support it, it isn't required by the OpenGL spec, and AFAIK many mobile chips do not. > > Anyway, all that to say, it would be nice to support it, but it will come at a performance cost, especially for software implementations.
(In reply to comment #5) > Anyway, all that to say, it would be nice to support it, but it will come at a performance cost, especially for software implementations. Having full-scene antialiasing only for hardware implementations would be better than no full-scene antialiasing at all. But yes, for software implementations you might not want the performance hit, and thus it is nice that the SVG specification leaves this to the discretion of the implementor. Here's an example of how these antialiasing artifacts can affect a "real-world" application: http://polymaps.org If you use the smooth zooming (either mousewheel or trackpad, WebKit nightly works best), you can see subpixel vertical and horizontal seams between the tiles. If you double-click and snap to an integral zoom level the artifacts go away. We could work around this problem by making the tiles slightly larger (e.g., 258x258) and have them overlap. But that doesn't work when you have transparency.
Check out the following paper for one way to approach the problem: http://w3.impa.br/~diego/projects/GanEtAl14/ There are some nice examples inside showing how most vector graphics rendering engines do the wrong thing w/r/t antialiasing of adjacent un-stroked solid shapes. Note also that antialiasing in OS X (and in most other contexts, unfortunately) is also incorrectly performed in gamma-encoded RGB space, rather than a linear color space, resulting in changes to apparent line/shape thickness as zoom level changes. Unfortunately that’s probably not fixable at this point, since digital fonts have all been designed assuming the incorrect behavior for the past 20 years, so when it’s handled correctly they end up looking spindly (e.g. look at a rasterized LaTeX file converted to PDF and compare to a vector version of the same as emitted by pdflatex; the raster file when downscaled in OS X Preview.app will have much thinner looking type than the vector version, because the image resizing is done correctly in linear RGB space, whereas the vector antialiasing is not; both will print identically).
Specifically, see http://w3.impa.br/~diego/projects/GanEtAl14/sample.html?contour for examples of wrong behavior in Quartz, Webkit (apparently these render slightly differently), Qt, Cairo, Windows 8, Adobe Reader, etc.