search

Letractively / svgweb

Automatically exported from code.google.com/p/svgweb
Other
0 stars 0 forks source link

Get large SVG file with lots of PATH nodes where PATH node data has lots of new lines in it faster #287

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
The SVG file in issue 277 is quite slow on SVG Web but fast on Safari and 
Firefox Native. Find out 
what is up and if we can get it faster.

Original issue reported on code.google.com by bradneub...@gmail.com on 15 Sep 2009 at 8:19

GoogleCodeExporter commented 8 years ago 
The SVG file can be grabbed off of Issue 277.

Original comment by bradneub...@gmail.com on 15 Sep 2009 at 8:20

GoogleCodeExporter commented 8 years ago 
hi,

i know SVG path. 
May i search the bottleneck and the solution ?

Original comment by lr.b21...@gmail.com on 15 Sep 2009 at 10:32

GoogleCodeExporter commented 8 years ago 
Sure BLR, go for it.

Original comment by bradneub...@gmail.com on 15 Sep 2009 at 6:01

GoogleCodeExporter commented 8 years ago 
i suggest two functions based on String or Array for replace comment strip in 
svg.js

    function stripoutArray( svg)
    {
      var strippedSVG = svg;
      var ar = new Array();
      var start = 0;
      var end = svg.indexOf('<!--');
      while( end != -1)
      {
        ar.push( svg.substring(start, end));
        start = svg.indexOf('-->', end + 4);
        start += 3;
        end = svg.indexOf('<!--', start);
      }
      if ( start < svg.length)
        ar.push( svg.substring(start));
    return ar.join('');
    }

    function stripoutString( svg)
    {
      var ret = '';
      var start = 0;
      var end = svg.indexOf('<!--');
      while( end != -1)
      {
        ret += svg.substring(start, end);
        start = svg.indexOf('-->', end + 4);
        start += 3;
        end = svg.indexOf('<!--', start);
      }
      if ( start < svg.length)
         ret += svg.substring(start);
    return ret;
    }

Original comment by lr.b21...@gmail.com on 25 Sep 2009 at 8:06

GoogleCodeExporter commented 8 years ago 
one function in svg.js

Original comment by lr.b21...@gmail.com on 25 Sep 2009 at 8:07

Attachments:

GoogleCodeExporter commented 8 years ago 
Thanks BLR! This is good work; I'll get a chance to look at it more after the 
SVG
Open conference in a week or two.

Original comment by bradneub...@gmail.com on 25 Sep 2009 at 8:18

GoogleCodeExporter commented 8 years ago 
comparing results between stripoutArray, stripoutString, stripout of SVGWeb on
different browsers.

t=referent time of stripoutArray function.

FireFox v3.5.3
--------------
    stripoutArray      t
    stripoutString     t x 0.9
    SVGWeb             t x 981

Safari v4.0.3
--------------
    stripoutArray      t
    stripoutString     t x 1
    SVGWeb             t x 420

Chrome v3.0
--------------
    stripoutArray      t
    stripoutString     t x 0.8
    SVGWeb             t x 644

Opera v10.0
--------------
    stripoutArray      t
    stripoutString     t x 0.6
    SVGWeb             fail

IE v6
--------------
    stripoutArray      t
    stripoutString     t x 51
    SVGWeb             -

IE v7
--------------
    stripoutArray      t
    stripoutString     t x 60
    SVGWeb             -

IE v8
--------------
    stripoutArray      t
    stripoutString     t x 0.9
    SVGWeb             t x 575

stripoutArray is the best function.

Original comment by lr.b21...@gmail.com on 29 Sep 2009 at 9:12

GoogleCodeExporter commented 8 years ago 
time of prog10int1.svg display (issue 277) on my computer (Vista, FireFox 3.5.3)
version : Umber Hulk (September 16th, 2009 Release)

results (manual measure):
    - version without change      : 50s
    - version with stripoutArray  : 30s
    - version with stripoutArray 
      and a other algorithm (path):  9s

Original comment by lr.b21...@gmail.com on 29 Sep 2009 at 9:31

GoogleCodeExporter commented 8 years ago 
I write a version with drawPath function and Vector class.
The program win 2 seconds (version with stripoutArray and a other algorithm
(path)drawPath function and Vector class) => result 7 seconds (manual measure).

comments :
- compile with Flex 4 (codename Gumbo) Beta 1 (4.0.0.7219) 
- run with Flash reader version 10.
- problem with fill-rule or fill on some paths

Original comment by lr.b21...@gmail.com on 4 Oct 2009 at 10:01

GoogleCodeExporter commented 8 years ago 
results of firebug profiler (version version with stripoutArray and a other 
algorithm)

                    call   % time
sendToFlash()         2     37.37%
_cleanSVG()           1     20.81%
_addTracking()        1     13.19%
_executeScript()      1      7.79%
parseXML              2      5.47%
__flash__escapeXML    2      5.34%
guid              10827      3.83% 
_generateID()      5413      2.49%
...

Original comment by lr.b21...@gmail.com on 4 Oct 2009 at 10:30

GoogleCodeExporter commented 8 years ago 
I finish to rewrite SVGPathNode program. I want to test Q,q,T,t,A,a command in 
path tag.
Do you know where i can find some files with those command ?
Thanks,

Original comment by lr.b21...@gmail.com on 14 Oct 2009 at 4:02

GoogleCodeExporter commented 8 years ago 
Note to myself to test and apply BLRs latest speedup patch on this.

Original comment by bradneub...@gmail.com on 19 Oct 2009 at 11:16

GoogleCodeExporter commented 8 years ago

Original comment by bradneub...@gmail.com on 20 Oct 2009 at 12:37

GoogleCodeExporter commented 8 years ago 
I test my new function (a other algorithm with stripoutArray) with a other file 
(
europe.html  in issue 354) on my computer (Vista, FireFox 3.5.3,Flash reader 
version 10).

results (manual measure):
- SVG Web version      : 45s
- new function with stripoutArray  : 20s
- new function with stripoutArray with drawPath function, and Vector class 
(Flex4
Beta 1 (4.0.0.7219)):  2s

comments:
- no display Italy and England with new function with stripoutArray => bug
- For display Russia, it's very long. For example, ith my new function with
stripoutArray :  10s for all countries without Russia, 10s for Russia.
Perharps, an explanation : for draw the Russia, the path have 62561 characters 
and a
matrix calculation.
- the drawpath function is very fast with this file.

Original comment by lr.b21...@gmail.com on 20 Oct 2009 at 9:22

GoogleCodeExporter commented 8 years ago 
I test my new function (a other algorithm with stripoutArray) with a other file 
(
wikipedia-logo.html svgweb/tests/non-licensed/wikipedia directory) on my 
computer
(Vista, FireFox 3.5.3,Flash reader version 10).

results (manual measure):
- SVG Web version      : 16s
- new function with stripoutArray  : 13s
- new function with stripoutArray with drawPath function, and Vector class 
(Flex4
Beta 1 (4.0.0.7219)):  7s

comments:
- with my function, i do'nt win time
- the drawpath function is very fast with this file.

Original comment by lr.b21...@gmail.com on 21 Oct 2009 at 6:16

GoogleCodeExporter commented 8 years ago 
Hi,

I propose you some modifications concerning SVGPathNode and SVGNode files.
Testpath.zip contains my files of test.

Regards,

blr

Original comment by lr.b21...@gmail.com on 1 Nov 2009 at 4:45

Attachments:

GoogleCodeExporter commented 8 years ago 
Hi,

I adapted my SVGPathNode program for Javascript.
I spend all the data in the form of String with the other parameters.
I put all in the static Number Array.
Everything is well and fast (2-3s).
But the display is even longer than with the other version (50s)
40s in the display function (graphics call).
What is  the access to the static variables are  slower than the access to the 
other
variables?
Do you know ?
Thanks,

Original comment by lr.b21...@gmail.com on 4 Nov 2009 at 8:14

GoogleCodeExporter commented 8 years ago 
Hi,

To increase the speed of display, I work on files in testpath.zip (in complex
directory). I noticed that often these big files have a luxury of details; 
sometimes
useless. I have an idea of optimization but sometimes it is degrade a little the
quality of the result. 

I join two files to show the obtained differences on the worst result.

I win some seconds on my computer (Vista, FireFox 3.5.5,Flash reader version
10)(manual measure) :
europe.html native : 2s
europe.html with SVG Web and my optimization : 12s

wikipedia logo native : 3s
wikipedia logo with SVG Web and my optimization : 8s

LayerSelect (meteo map) : 1s
LayerSelect (meteo map)with SVG Web and my optimization : 4s

what do you think of my idea?
This optimization could it be optional like debug option ?

Original comment by lr.b21...@gmail.com on 11 Nov 2009 at 5:53

Attachments:

GoogleCodeExporter commented 8 years ago 
We could let files expose what tradeoffs they want using the optimize-speed 
value for
shape-rendering:

http://www.w3.org/TR/SVG/painting.html#ShapeRenderingProperty

Original comment by bradneub...@gmail.com on 11 Nov 2009 at 6:54

GoogleCodeExporter commented 8 years ago 
Yes, it's a good idea.
However, i have many others ideas of optimization.
Some are "soft" and others are "hard". Today, it's "hard" optimization.
Some will have parameters by default but in some cases, it would be good that 
these
parameters are modified.
What do you think ?

Original comment by lr.b21...@gmail.com on 11 Nov 2009 at 8:05

GoogleCodeExporter commented 8 years ago 
Hi,

Would be it possible to have our namespace of SVG Web ?
We could have our own parameters without changing the SVG.
for example :

<path d="..." shape-rendering="optimizeSpeed" svgweb:speed="..."/>

Is it a good idea?

Original comment by lr.b21...@gmail.com on 12 Nov 2009 at 8:58

GoogleCodeExporter commented 8 years ago 
Hi BLR, the correct approach is for us to support the optimize-speed or
optimize-legibility CSS rules:

http://www.w3.org/1999/07/06/WD-SVG-19990706/render.html#RenderingProperties

Note to self: review BLR's latest Path diffs as well. Marking as Patch.

Original comment by bradneub...@gmail.com on 19 Nov 2009 at 9:42

GoogleCodeExporter commented 8 years ago 
Hi,

ok, one attribute for optimize-speed What methods do we have to choose?

some methods in attach file

Original comment by lr.b21...@gmail.com on 29 Nov 2009 at 4:03

Attachments:

GoogleCodeExporter commented 8 years ago 
Jon Ferraiolo also has some good ideas on this:

My initial proposal (below) was to use regexp magic to convert a path data 
string
into JSON, and then use a (hopefully very fast) JSON parser to convert into 
native
ActionScript objects (e.g., arrays, strings, numbers). This approach would run
lickity-split in a modern browser. However, to my surprise, it appears that
ActionScript3 still does not include a native JSON parser, and instead it 
appears you
have to import a JSON library as an ActionScript "class". I would guess that an
ActionScript class isn't nearly as fast as a native implementation would be.

A variation of this regexp trick that might be faster than JSON would be to 
leverage
the XML/E4X parser that is implemented natively in the Flash player. Here is 
some
JavaScript for converting a path data string into an XML string that then can be
parsed by the Flash player's E4X parser:

<script>
var path="M100 100c20,50 , 10,20,30,30z";
var p1 = path.replace(/[ ]*[, ][ ]*/g,' ');
var p2 = p1.replace(/([a-zA-Z])([^a-zA-Z]*)/g,'<$1>$2</$1>');
var p3 = p2.replace(/([0-9]+)/g,'<n>$1</n>');
var p4 = p3.replace(/^(.*)$/,'<P>$1</P>');
alert(p4);  

/* The above alert prints out some XML that looks like this (I added newlines 
for
readability):
<P>
   <M>
      <n>100</n>
      <n>100</n>
   </M>
   <c>
      <n>20</n>
      <n>50</n>
      <n>10</n>
      <n>20</n>
      <n>30</n>
      <n>30</n>
   </c>
   <z>
   </z>
</P>
*/
</script>

I'm not an ActionScript guy, but I believe that the string in p3 above can be 
parsed
directly into ActionScript objects as follows:

      var PathData = new XML(p4);  // PathData is an XML object

To loop through the path data commands, I think this will work.

      var Commands = PathData.children; // Returns an XMLList
      for (var i:uint = 0; i < Commands.length(); i++) { // XMLList requires length()
function
        var Command = Commands[i]; // Another XMLList
        var CommandName = Command.toString(); // Tagname, such as "M", "c" or "z"
        for (var j:uint = 0; i < Command.length(); i++) {
          var Numvalue = Number(Command[j]); // Value of an <n> element
        }
      }

Original comment by bradneub...@gmail.com on 30 Nov 2009 at 5:49

GoogleCodeExporter commented 8 years ago 
BLR sent me some profiling info on this October 23rd; attaching to this bug so 
it
doesn't get lost.

Original comment by bradneub...@gmail.com on 30 Nov 2009 at 5:51

Attachments:

GoogleCodeExporter commented 8 years ago 
Which informations want you?

Original comment by lr.b21...@gmail.com on 1 Dec 2009 at 9:12

GoogleCodeExporter commented 8 years ago 
Jon Ferraiolo proposal

It's an interesting idea 
In my comment of Nov 04, 2009, I tested a similar idea.
first step : I analyse all datas of all paths in javascript. I put all datas in 
a string.
In Actionscript, i split this string from array. 
Second step : Actionscript do not work on the data. When SVG Web want to 
display a
path, the program call the graphics function.

first step spend 2-3s.
Second step spend 50s on my Nov 04, 2009 example.

My young experience on this subject show that there are two bottlenecks :
- When there are many object alloc, the gc work (it's normal) and it spend many 
times.
- the graphics calls is slow in flash version 9. It is not very visible for 
hundred
curves or one thousand curves. For example, in europe.html, one path content 
1100 C
commands. SVG Web transtate to 4400 Q commands ... In this file, there are 8250 
C
commands. SVG Web draw 33000 Q commands ...  There 11 A commands which add many
little curves. no comments ;-)

my 29 nov, 2009 ideas are :
- a line draw is faster than a curve draw
- To draw many of the small drawing is less fast than to draw one shape.

These two ideas can be mixed.

Original comment by lr.b21...@gmail.com on 1 Dec 2009 at 11:40

GoogleCodeExporter commented 8 years ago

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

GoogleCodeExporter commented 8 years ago

Original comment by bradneub...@gmail.com on 17 Dec 2009 at 10:20

GoogleCodeExporter commented 8 years ago 
The main initial bottleneck is actually on the JavaScript side in the cleanSVG
method; this method takes ~75 seconds to run! The issue is further in the part 
where
we strip out comments such as <!-- -->:

var commentRE = /<!\-\-/g;
      RegExp.lastIndex = 0; // reset global exec()
      match = commentRE.exec(svg);
      var i = 0;
      var strippedSVG = svg;
      while (match && RegExp.lastMatch) {
        // get the text of the comment
        var endIndx = RegExp.rightContext.indexOf('-->') + 3;
        var comment = '<!--' + RegExp.rightContext.substring(0, endIndx);

        // now strip it out
        strippedSVG = strippedSVG.replace(comment, '');

        // find next match
        match = commentRE.exec(svg);
        i++;
      }
      svg = strippedSVG;

Need to figure out a way to make this faster; there are many many comments in 
the SVG
file referenced by this bug.

Original comment by bradneub...@gmail.com on 17 Dec 2009 at 10:42

GoogleCodeExporter commented 8 years ago 
If I manually remove the comments from the SVG file, the time goes from 75 to 25
seconds, so the comment code are definitely the current primary bottleneck.

Original comment by bradneub...@gmail.com on 17 Dec 2009 at 11:26

GoogleCodeExporter commented 8 years ago 
I've made a testing case that tracks this in 
tests/non-licensed/issue287/LayerSelect.html

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

GoogleCodeExporter commented 8 years ago 
As a temporary workaround to the original file given in Issue 277 you can 
remove all the comments in the file 
and also remove all the new lines in each d="" statement; I believe that will 
speed thing up significantly.

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

GoogleCodeExporter commented 8 years ago 
Some interesting data: removing the comments from the test file has a large 
affect on performance. I thought 
that removing the spaces and new lines from the 'd' elements would also affect 
performance, but they don't 
seem to.

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

GoogleCodeExporter commented 8 years ago 
This issue was closed by revision r1095.

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