Inkscape slow to load 30MB SVG file (vector data only)

[ChristianSchaller]

The attached SVG file fails to load into Inkscape, it is an SVG generated from a GStreamer pipeline using graphviz

File info from SVG source:
<!-- Generated by graphviz version 2.26.0 (20091210.2329)
<svg width="29890pt" height="114083pt" viewBox="0.00 0.00 29890.00 114083.00" (…)>

[ChristianSchaller (uraeus)]

Actually it did load in the end, it just took a long time and Inkscape gave no visual cue indicating something was happening.

[ChristianSchaller (uraeus)]

And the performance of Inkscape is abysmal with it loaded, so I guess the bug report should be retitled. SVG file brings Inkscape to its knees.

[su_v (suv-lp)]

Failure to load the 30MB file (all vector data) not reproduced with Inkscape 0.48.3.1 and 0.48+devel r11664 on OS X 10.7.4
(MBP 13", 2.4 GHz Intel Core i5, 8GB 1333MHz DDR3)

Average times to load the file (varies +/- 15 sec in repeated tests):

Chillida:bug su_v$ time inkdefault 0483 1049562-pipeline.PLAYING.svg --verb=FileQuit

real 3m28.912s
user 3m13.101s
sys 0m2.315s
Chillida:bug su_v$
Chillida:bug su_v$ time inkdefault trunk 1049562-pipeline.PLAYING.svg --verb=FileQuit

real 1m56.720s
user 1m47.606s
sys 0m1.934s
Chillida:bug su_v$

-> load time in current trunk is half the time of current stable. This is much closer to the ~55-60s for example Chromium takes to render the file.

[su_v (suv-lp)]

Correction:
> load time in current trunk is half the time of current stable

Not really half (mathematically), but load time has noticeably improved ;)

[su_v (suv-lp)]

ChristianSchaller wrote:
> I guess the bug report should be retitled.

Done.

[ChristianSchaller (uraeus)]

How is performance for you once loaded? for me the UI chokes if I try to zoom in for instance and takes forever to re-render.

[su_v (suv-lp)]

> How is performance for you once loaded? for me the UI chokes if
> I try to zoom in for instance and takes forever to re-render.

- Zooming in/out, and scrolling after having settled on an area at 1:1 zoom is much faster in trunk (changing the zoom level is still slow, but scrolling is much more fluent than in stable 0.48.3.1).
- Adding new objects and editing or moving them is unusably slow in current trunk (likely related to bug #906952 and the preciser bbox calculation). It's a bit better in stable 0.48.3.1, which on the other hand is much slower when changing zoom levels, and also when scrolling.

Overall, this is not really a file one wants to manually edit in Inkscape, even with lots of patience (Caveat: I'm not a code developer myself - doing mostly bug triage. Based on my experience my impression is that it is not the high number of objects (22540 objects in the top-level group, many of them (possibly nested) groups again) by itself, but actually the size of the "page" (the width/height and viewBox attributes of the <svg> element: 29'890 x 114'083 SVG user units), which mostly exhausts Inkscape's current capabilities. Even if maximally zoomed out (1%), the diagram can't be displayed completely (on a 15" screen at most about 45% of the height are visible in my test).

[Beluga (buovjaga)]

Slow to open, slow to re-paint on scrolling, even slower to zoom. 6th gen Intel CPU, 32GB mem.

Arch Linux 64-bit, KDE Plasma 5
Inkscape 0.92pre1 15073 (GTK3)