Slow performance (and crashes) for large SVG files
haykpetros opened this issue · 7 comments
Currently one can use Init custom events handler to be notified when plugin is done initializing. But for large documents this can take a while, so it will be great if another event (maybe progress?) is added that will be raised on each step to make initialization process more interactive for end user.
Library initializes very fast. There are no expensive steps in it. The only thing that may take time is SVG preload (that should be done outside of the library). So if we would add multiple initialization events, they would fire all at once. So there is no real use for this (except maybe debugging).
This could be a useful feature for the plugin system discussed in here #98.
Actually I did that already and still after SVG is loaded it takes significant amount of time to initialize plugin. May I ask what exactly is happening during that process?
Can you please post an example so that it will get easier to debug.
There are not many things happening at initialization time, but you see that for yourself as the code is open source.
Please use following link:
http://codepen.io/anon/pen/OyPwpb?editors=101.
You will see that document will load just fine. Then uncomment Line 25 in JS window and observe browser crashing:
// useSvgPanZoom($svg.get(0));
You will need to enable Cross Origin Resource Sharing (CORS) in case you run into problems.
I thought that you're talking about plugin being slow. For crashing you opened #145
There is one thing that is actually taking a lot of time. Zooming and panning is done by updating transform attribute of a g element. In your SVG you don't have a parent g element, instead it has ~70k rectangles. You can see here that if an SVG doesn't have a viewport then it will create a top-level g element and will copy all other elements into it. That's what takes so much time.
The solution is simple: add a parent g element into your SVG and insert all elements into it. You may also have multiple groups and use zooming and panning only for one of them (you can read more about that in documentation).
Very interesting, thanks for pointing that out. Any idea why it is fine with 50K elements, but then suddenly crashes with 70K elements?
It didn't crash for me, just took a while. So probably it depends on your computer resources (like memory and CPU)