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