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

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

Received on Friday, 29 May 2015 06:59:59 UTC