RE: Overlapping Lines - and the edges of those lines - artifacts in rendering.

Such an option to get precise rendering isn’t supported in some way, is a cause for SVG not being adopted for technical graphic usage where precision matters.  Hopefully we can come to a solution that works.  I imagine the users that need this precision (industrial users who’s graphics are not discoverable on the web as they sit behind firewalls and on intranets and contain intellectual property) are willing to sacrifice some performance for the more important “draw what I asked you to” precision.

Thomas
--
Thomas Smailus, Ph.D.  P.E.
Boeing Information Technology

From: Amelia Bellamy-Royds [mailto:amelia.bellamy.royds@gmail.com]
Sent: Thursday, May 28, 2015 16:01
To: Smailus, Thomas O
Cc: www-svg@w3.org
Subject: Re: Overlapping Lines - and the edges of those lines - artifacts in rendering.

What you're seeing is the result of the browsers' anti-aliasing approach  (and applies in all browsers, as far as I know -- Chrome, at least, uses the same approach as Firefox and IE).

Each individual shape is anti-aliased before compositing the shapes together, creating a shape (or line in this case) with partially transparent fringes 1 pixel wide.  These partially transparent fringes blend together, even if the shapes themselves are opaque and the official geometric bounds of one shape completely overlaps the others.

For this particular example (with strict horizontal/vertical lines), you can get an acceptable result by applying `shape-rendering: crispEdges`, which tells the browsers to round each individual shape to exact pixel borders instead of applying anti-aliasing.  However, the same approach is less satisfactory when using curves or diagonal lines, as you lose the smoothing effect of the anti-aliasing.

http://jsfiddle.net/thomassmailus/aLm6zpe6/7/


As to whether this is a spec problem or a browser problem:

With the exception of the `shape-rendering: crispEdges` option, I don't think there is anything in the SVG specs that discusses how anti-aliasing should be applied.  So it is a bit of an undefined behavior on the spec side.  That said, the section on clipping paths does acknowledge that clipping paths can have aliased edges, which could create similar counter-intuitive results.  For example, if you drew a shape and then applied a clipping path that exactly excluded the same shape, you could still have a visible fringe because of the anti-aliasing.

Geometrically-precise clipping and compositing could have significant impacts on performance. Browsers would need to use vector operations for compositing in order to keep track of the exact geometry, before rasterizing (and anti-aliasing) the final result.  This would limit the options for optimizing painting, and would preclude many types of hardware optimization.

In other words, I don't think you will find support for making geometrically-precise compositing a requirement.  However, it may be worth considering a new rendering hint property, whereby authors could request this behavior -- and accept the performance impacts!

~ Amelia BR


On 28 May 2015 at 15:57, Smailus, Thomas O <Thomas.O.Smailus@boeing.com<mailto:Thomas.O.Smailus@boeing.com>> wrote:
I’ve been working an issue where the SVG rendering engines in Firefox 31 and IE 11 (because that’s what I have to test against) both render some dark pixels in an area where there should be nothing but white.

This fiddle (http://jsfiddle.net/thomassmailus/aLm6zpe6/ ) renders a dashed red-white line as follows:

Draws a black line, draws a white line right on top of it (same points, same stroke-width) and then draws a dashed red line over the white line (same points, same stroke-width)

The edges of the red and particularly noticeable in the white regions, have a dark (black) edge.  It is an artifact of the edge of the rendered area of the black line at the bottom of the stack of 3 lines.  However, as the definitions of the lines vary ONLY in color, the black should be completely covered up by the red and white.

I would expect the only rendered pixels would be the white and red.  The problem is as the lines get thinner, the dark edge is still there, and then the red/white dashed lines start to look like dark gray lines with hits of red on them.. rather than red/white dashed lines.

Is this a weakness of the SVG standard  - or a common error in the painting engines in Firefox and Internet Explorer?


Thomas Smailus
Boeing