Parsing complicated long path statements extremely slow

[GoogleCodeExporter]

I've long known that parsing path statement data is the primary bottleneck 
in SVG Web. A user recently gave me several path testing files that are 
extremely slow. I have checked them into tests/non-licensed/vector-
text1. Here are the performance results:

All files are roughly 500K of path data:

Environment: Safari 4, Laptop Power Setting on Better Performance, data-
debug="false", r1020 of SVG Web

svgweb-test-by1.html (each path statement is a single z-path - roughly 
one letter): 1 1/2 minutes

svgweb-test-by10.html (each path statement has 10 z-paths - roughly 
ten letters): 1 1/2 minutes

svgweb-test.html (each path statement is one line of text as paths): 10 
minutes

The linear oriented approach is roughly an order of magnitude slower than 
having individual z-paths or 10-sets of z-paths. All of them are obviously 
much too slow.

This confirms what I've known, that path parsing (and possibly path 
rendering) on the Flash side of SVG Web is the primary current bottleneck. 

To investigate this I will probably begin by creating a pure ActionScript 
class that attempts to parse lots of Path data. I think maybe Flash has n^2 
degradation in performance on the length of the path strings.

Original issue reported on code.google.com by bradneub...@gmail.com on 11 Feb 2010 at 12:24

[GoogleCodeExporter]

Just added tests/non-licensed/perf/test6, which tests long path statements, 
lots of
path statements, and the exact data inside svgweb-test.svg as stand alone
ActionScript classes. None of them replicate the slowness, so I'll have to try
another tack.

Original comment by bradneub...@google.com on 12 Feb 2010 at 8:01

[GoogleCodeExporter]

So I found the culprite; it's no longer string parsing at all. In
tests/non-licensed/test7 I've tracked it down to the draw() method, specifically
whenever we make curves with drawSprite.graphics.curveTo(). It looks like the 
Flash
curveTo method is _very_ slow. 

Original comment by bradneub...@gmail.com on 12 Feb 2010 at 10:28

[GoogleCodeExporter]

Jeff Schiller also pointed me to the Flash 10 drawPath method on the Graphics 
object,
which claims that its faster for curves:

http://help.adobe.com/en_US/AS3LCR/Flash_10.0/flash/display/Graphics.html#drawPa
th%28%29

I'll do some benchmarking

Original comment by bradneub...@gmail.com on 13 Feb 2010 at 12:01

[GoogleCodeExporter]

I found the bottleneck! It turns out that drawSprite.graphics.curveTo is _very_ 
slow
when the miter join style is turned on, in nodeBeginStroke in SVGNode:

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

If I comment things out as you see above the speed goes from 10 minutes to ~2.5 
seconds!

Still investigating how this impacts things and how this might diverge from SVG 
spec.
Other samples are _much_ faster, like the photorealistic car drawings that used 
to be
slow.

Original comment by bradneub...@gmail.com on 19 Feb 2010 at 6:42

[GoogleCodeExporter]

This is a duplicate of Issue 437.
Miter is the default which is a bummer.
Your results are perplexing because I ran a bunch of tests and did not find that
changing the join style made much difference. Perhaps I did not run the tests
correctly. Sigh. 

What platform did you test on?

Original comment by grick23@gmail.com on 20 Feb 2010 at 4:12

[GoogleCodeExporter]

Mac OS X 10.5.8 with Flash 10. I ran the sample in
tests/non-licensed/vector-text1/svg-test.html which has a huge number of 
curves. I'm
thinking the right way to go is to support the shape-rendering property, expose 
it so
that the Flash side of things can see what the value is, and make the default 
for SVG
Web be 'optimizeSpeed'. The effect on performance is huge. Page authors can
optionally specify shape-rendering to be 'geometricPrecision' which would then
default to the Miter limit. If we default 'shape-rendering' to 'optimizeSpeed', 
we
should just make the Miter be Flash's default in nodeBeginStroke if no Miter is
specified. This would then make the common case very fast for people.

Original comment by bradneub...@gmail.com on 20 Feb 2010 at 7:01

[GoogleCodeExporter]

Shape-rendering property is specified here in the spec:

http://zvon.org/xxl/svgReference/Standard1.1/painting.html#ShapeRenderingPropert
y

The spec actually defaults it to auto, which says:

"Indicates that the user agent shall make appropriate tradeoffs to balance 
speed,
crisp edges and geometric precision, but with geometric precision given more
importance than speed and crisp edges."

I think its probably appropriate to keep it as auto but in the spirit of what 
it says
about balancing performance in nodeBeginStroke we can default to Flash's joint 
style
instead of Miter if it is not specified.

Original comment by bradneub...@gmail.com on 20 Feb 2010 at 7:04

[GoogleCodeExporter]

In reply to comment 7:

As a general comment, I'd suggest using the current editor's draft [1] for 
Second
Edition of the SVG 1.1 specification:

http://dev.w3.org/SVG/profiles/1.1F2/publish/

There are lots of clarifications and it's probably (very) close to the final
document. ;-)

As a side note, the part which was referenced is exactly the same [2]:

http://dev.w3.org/SVG/profiles/1.1F2/publish/painting.html#ShapeRenderingPropert
y

Original comment by helder.magalhaes on 20 Feb 2010 at 1:08

[GoogleCodeExporter]

Fixed with Issue 437 and Issue 438.

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

• Changed state: Fixed