| Summary: | impress/draw get extremely slow with documents including svg in libo 4.0 beta 1 | ||
|---|---|---|---|
| Product: | LibreOffice | Reporter: | Callegar <sergio.callegari> |
| Component: | LibreOffice | Assignee: | Not Assigned <libreoffice-bugs> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | CC: | alexngould, dg1727, dtardon, fdbugs, glutanimate, hans, jmadero.dev, michael.meeks, mihamina.rakotomandimby, roberto.braga, thb, xiscofauli, zmogas |
| Priority: | medium | Keywords: | bibisected, regression |
| Version: | 4.0.0.3 release | ||
| Hardware: | All | ||
| OS: | All | ||
| See Also: |
https://bugs.documentfoundation.org/show_bug.cgi?id=60425 https://bugs.documentfoundation.org/show_bug.cgi?id=82214 |
||
| Whiteboard: | BSA | ||
| Crash report or crash signature: | Regression By: | ||
| Bug Depends on: | |||
| Bug Blocks: | 100023, 107817, 108075 | ||
| Attachments: |
test svg image
kcachgrind screenshot ... |
||
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 4.2.0.4) on Mac OS X 10.9.1 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. 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! Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit] It looks like a duplicate of bug 101083 *** This bug has been marked as a duplicate of bug 101083 *** It looks like a duplicate of bug 101083 *** This bug has been marked as a duplicate of bug 101083 *** |
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