Created attachment 71663 [details]
test svg image
I have presentations with svg images. They were usable with libo 3.6.4.
They are now extremely slow in 4.0.
1) file load takes 4 times what it used to thake in 3.6.
2) generation of thumbnails takes a very long time
3) when you run a presentation, the transition from one slide to the next one takes a loooong time if the next one containse an svg image.
To see the problem, try creating a presentation with the attached svg image.
Operating System: Ubuntu
Last worked in: 184.108.40.206 release
Takes a long time to import for me too - I'll run a profile.
Interesting - the basic problem here is that this entire image is a single self-intersecting SVG path. The new svgio/ code demands that the code be non-self-intersecting and so spends almost the entirety of the import time ~132bn CPU cycles inside a single call to basegfx::tools::createNonzeroConformable.
I guess the fundamental problem is that that method is rather slow - N^2 in number of points at least AFAICS and it is rather unclear to me that we should be doing this conform at import rather than rasterise.
Amusingly if instead you simply load the image as a draw file - the code takes another path: so file->open of the same SVG would be a workaround for you. That effectively converts the SVG to ODF rather than embedding SVG, and is several orders of magnitude faster.
Anyhow - thanks for the interesting test-shape, hope the workaround helps. Any thoughts Thorsten ?
All the best.
Created attachment 71722 [details]
kcachgrind screenshot ...
(In reply to comment #2)
> Amusingly if instead you simply load the image as a draw file - the code
> takes another path: so file->open of the same SVG would be a workaround for
> you. That effectively converts the SVG to ODF rather than embedding SVG, and
> is several orders of magnitude faster.
Though likely with subtly wrong fills or clips -
> Anyhow - thanks for the interesting test-shape, hope the workaround helps.
> Any thoughts Thorsten ?
Beyond optimizing the basegfx method - provide nonzero winding rule fills in drawinglayer and vcl (canvas already has it). That way, no need for pre-processing.
*** Bug 61230 has been marked as a duplicate of this bug. ***
Just to note out that as of Bug 61230 (marked as a duplicate) this problem affect also writer (and I guess calc too).
I can confirm this issue affect calc (LibreOffice 220.127.116.11) on Mac OS X 10.9.1
This also affects me, running 18.104.22.168 on Archlinux.
I have a Writer document full of drawings made of SVGs and it's very slow.
Bibisect results in 43all:
Unfortunately it seems that there was a long period after the change in question when presentations with embedded SVG didn't work at all, so I'm not sure how useful this is. It sounds like mmeeks may have an idea which specific change is at fault
There are only 'skip'ped commits left to test.
The first bad commit could be any of:
We cannot bisect more!
Migrating Whiteboard tags to Keywords: (bibisected)
It looks like a duplicate of bug 101083
*** This bug has been marked as a duplicate of bug 101083 ***