Bug Hunting Session
Bug 58420 - impress/draw get extremely slow with documents including svg in libo 4.0 beta 1
Summary: impress/draw get extremely slow with documents including svg in libo 4.0 beta 1
Status: RESOLVED DUPLICATE of bug 101083
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
4.0.0.3 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords: bibisected, regression
: 61230 (view as bug list)
Depends on:
Blocks: Draw-UX Impress-UX Scrolling-PageUpDown
  Show dependency treegraph
 
Reported: 2012-12-17 16:43 UTC by sergio.callegari
Modified: 2017-09-14 10:44 UTC (History)
13 users (show)

See Also:
Crash report or crash signature:


Attachments
test svg image (227.29 KB, image/svg+xml)
2012-12-17 16:43 UTC, sergio.callegari
Details
kcachgrind screenshot ... (429.56 KB, image/png)
2012-12-18 11:37 UTC, Michael Meeks
Details

Note You need to log in before you can comment on or make changes to this bug.
Description sergio.callegari 2012-12-17 16:43:44 UTC
Created attachment 71663 [details]
test svg image

Problem description:

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: 3.6.4.3 release
Comment 1 Michael Meeks 2012-12-17 21:43:40 UTC
Takes a long time to import for me too - I'll run a profile.
Comment 2 Michael Meeks 2012-12-18 11:36:55 UTC
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.
Comment 3 Michael Meeks 2012-12-18 11:37:16 UTC
Created attachment 71722 [details]
kcachgrind screenshot ...
Comment 4 Thorsten Behrens (CIB) 2013-01-10 16:40:57 UTC
(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.
Comment 5 Björgvin Ragnarsson 2013-05-15 20:43:53 UTC
*** Bug 61230 has been marked as a duplicate of this bug. ***
Comment 6 Roberto braga 2013-08-30 08:03:17 UTC
Just to note out that as of Bug 61230 (marked as a duplicate) this problem affect also writer (and I guess calc too).
Comment 7 Manuel R. Ciosici 2014-02-23 10:19:37 UTC
I can confirm this issue affect calc (LibreOffice 4.2.0.4) on Mac OS X 10.9.1
Comment 8 Mihamina RAKOTOMANDIMBY 2014-05-28 08:26:13 UTC
This also affects me, running 4.2.4.2 on Archlinux.
I have a Writer document full of drawings made of SVGs and it's very slow.
Comment 9 Matthew Francis 2014-12-04 02:55:28 UTC
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:
7fd8bdb3b18f50ea0adbc0a5e611f6a844b23189
a67b874d60de1f1a44bef57a53a7b8a84db0ba58
46f9a799a00ba869957d7aa7650cae7fd2501394
d73160956706b297f4a7043d35e229f2e8566d5f
183a576d94de9a9439d580c8b81f335ab57cdbdc
221bf5c0db153e24c67ff29fe614af7cc010a356
79e02001f27d33b3b478324ab6fba5683413b4d9
e5973caebe5b9637f93a4da008d76b33b9d5ff6a
1f14665c5624bc7a502738aa8f4f2bd70a211e72
ba6eb41acb8df58f3009920f8ab8b32a3e1b764e
99f63b2b53c0e22baac045d54f502508d7150fef
We cannot bisect more!
Comment 10 Robinson Tryon (qubit) 2015-12-13 11:16:22 UTC Comment hidden (obsolete)
Comment 11 Xisco Faulí 2017-09-14 10:41:08 UTC Comment hidden (obsolete)
Comment 12 Xisco Faulí 2017-09-14 10:44:41 UTC Comment hidden (obsolete)