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

Do you have more information on that?

On Fri, May 29, 2015 at 2:59 AM, Tavmjong Bah <tav.w3c@gmail.com> wrote:

> On Thu, 2015-05-28 at 17:01 -0600, Amelia Bellamy-Royds wrote:
> > 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!
>
> A rendering hint might be a good idea... Nvidia has demonstrated
> rendering SVG on the GPU which is both very fast and gets rid of
> aliasing problems (they render at a higher resolution and then scale
> down). It might not be so far off in the future (in the life-time of the
> SVG 2 spec) that GPU rendering of SVG becomes more common.
>
> Tav
>
>
>
>
>
>


-- 
“I’ve always said, religion has given people great comfort in a world torn
apart by religion,”
 - Jon Stewart