Slow rendering with mitered corners

[GoogleCodeExporter]

I was having some performance problems rendering large SVG map files (paths
> 10,000 elements). I traced it down to the use of JointStyle.MITER as the
default joint style (SVGNode.nodeBeginStroke()).  I updated the the
function from

   var jointStyle:String = this.getStyleOrAttr('stroke-linejoin');
            if (jointStyle == 'bevel'){
                jointStyle = JointStyle.BEVEL;
            } else if (jointStyle == 'round') {
                jointStyle = JointStyle.ROUND;
            } else {
                jointStyle = JointStyle.MITER;
            }

and changed it to (null is JointStyle.ROUND):             

   var jointStyle:String = this.getStyleOrAttr('stroke-linejoin');
            if (jointStyle == 'bevel'){
                jointStyle = JointStyle.BEVEL;
            } else if (jointStyle == 'miter'){
                jointStyle = JointStyle.MITER;
            } else if (jointStyle == 'round') {
                jointStyle = JointStyle.ROUND;
            } else {
                //Default style was set to miter, this cause major slowness in
rendering complicated paths
                jointStyle = null;
            }

This rectified the problem and resulted in a 10 fold improvement on the
performance.

Original issue reported on code.google.com by antihad...@gmail.com on 2 Dec 2009 at 5:48

[GoogleCodeExporter]

The spec says miter is the default so I am not sure this is a good idea.
Why not change your SVG file?

Original comment by grick23@gmail.com on 2 Dec 2009 at 6:25

[GoogleCodeExporter]

Changing the SVN file is certainly an option, but the performance slowdown with 
the
mitered corners is really massive.  Most people using the library would not 
think to
adjust this setting when they hit a drawing performance issue.  Perhaps a 
adjustable
default setting in the library would be good compromise for both the purists 
and the
pragmatists? (PERFORMANCE vs QUALITY)

  Unfortunately, this is probably an issue inside of the flex drawing library itself.
 It also seems weird to me that rounded corners would be fast and mitered ones would
be so very slow.  Maybe there is a way to add a new Miter corner drawer that 
does not
have this issue?

Original comment by antihad...@gmail.com on 2 Dec 2009 at 7:36

[GoogleCodeExporter]

I think it may be worth doing something like you are suggesting. I just wanted 
to 
point out that it would be non-standard behavior.

If the performance penalty is really that high (as a google search seems to 
confirm 
and I'll do some testing as well to verify it) then it may be worth changing 
the 
default with the ability to override somehow. I'd also need to go through a lot 
of 
examples to see how visible this change would be.

Original comment by grick23@gmail.com on 2 Dec 2009 at 8:41

[GoogleCodeExporter]

We should probably start supporting the SVG RenderingProperty values; these can 
help
a document tell the renderer what is more important, performance or quality. 
I've
opened a bug to support these: Issue 438. Once we can parse these a given shape 
and
all its children can enforce different tradeoffs, and we can see for the
shape-rendering property whether it is to 'optimize-speed' which would mean we 
could
diverge from having Mitered corners to gain the speed improvement. This should 
help
with other areas too where similar issues exist.

Original comment by bradneub...@gmail.com on 2 Dec 2009 at 9:17

• Changed title: Slow rendering with mitered corners
• Added labels: Priority-Medium
• Removed labels: Priority-Low

[GoogleCodeExporter]

Original comment by grick23@gmail.com on 3 Dec 2009 at 1:21

• Changed state: Accepted

[GoogleCodeExporter]

I can confirm this issue has an extremely large affect on performance (about two
orders of magnitude performance difference for certain files with lots of SVG 
paths)
when the Mitered join style is on in Flash. I have some local changes on my disk
where I change SVGNode.as as follows:

+            // jointStyle="miter" is VERY VERY slow!!! HANDLE!!!
             drawSprite.graphics.lineStyle(line_width, line_color, line_alpha, false,
LineScaleMode.NORMAL,
-                                          capsStyle, jointStyle,
SVGColors.cleanNumber(miterLimit));
+                                          capsStyle); /*, jointStyle,
SVGColors.cleanNumber(miterLimit));*/

I'm just pasting this here so the code doesn't disappear. The correct thing to 
do is
to support the SVG RenderingProperty values, so a page author can specify 
whether
speed or quality is more important.

Original comment by bradneub...@google.com on 6 Apr 2010 at 12:11

[GoogleCodeExporter]

I'm implementing Issue 438 to solve this problem. I've had to differ slightly 
from the SVG standard though 
for shape-rendering when it comes to the Miter joints though. 

The SVG standard says that 'auto' on the shape-rendering property should 
optimize correctness over speed. 
However, we go against the standard for SVG Web on this point for two reasons:

* If a developer uses shape-rendering: optimizeSpeed for native SVG renderers, 
such as Firefox, the visual 
quality is very degraded -- there is no way to specify that only one renderer 
should be optimized for speed.
* The effect on performance is _huge_ for the Flash SVG Web renderer, by two 
orders of magnitude.

Since there is no straightforward way for a page author to want the major 
speedups for the Flash SVG Web 
but higher quality for native SVG I have to diverge slightly from the standard.

Original comment by bradneub...@gmail.com on 7 Apr 2010 at 10:40

[GoogleCodeExporter]

The test for this is at tests/non-licensed/vector-text1. Using the fix in Issue 
438 we now default to round 
joint style which gives an order of magnitude improvement of ~3 times (10 
minutes to about 0.5 seconds).

Original comment by bradneub...@gmail.com on 8 Apr 2010 at 12:08

• Changed state: Fixed