Bug 35211 - SVG should support full-scene antialiasing
: SVG should support full-scene antialiasing
Status: UNCONFIRMED
: WebKit
SVG
: 528+ (Nightly build)
: Macintosh Intel Mac OS X 10.6
: P2 Normal
Assigned To:
: http://graphics.stanford.edu/~mbostoc...
:
:
:
  Show dependency treegraph
 
Reported: 2010-02-21 03:08 PST by
Modified: 2012-11-30 08:10 PST (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2010-02-21 03:08:03 PST
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.
------- Comment #1 From 2010-07-06 12:56:11 PST -------
What section of the SVG 1.1 or 1.2 spec covers this?
------- Comment #2 From 2010-08-16 16:43:25 PST -------
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.
"""
------- Comment #3 From 2010-08-16 22:39:50 PST -------
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?
------- Comment #4 From 2010-08-17 14:28:06 PST -------
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.
------- Comment #5 From 2010-08-17 14:45:05 PST -------
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.
------- Comment #6 From 2010-08-17 14:48:07 PST -------
(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.
------- Comment #7 From 2010-08-20 11:27:50 PST -------
(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.