Download it now!
Bug 83426 - SVG's Load Slowly (Illustrator type)
Summary: SVG's Load Slowly (Illustrator type)
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
(earliest affected) release
Hardware: All All
: low minor
Assignee: Not Assigned
Keywords: bibisected, haveBacktrace, perf, regression
: 89728 94855 96880 114806 (view as bug list)
Depends on:
Blocks: SVG-Import Impress-Images
  Show dependency treegraph
Reported: 2014-09-03 08:27 UTC by Joel Madero
Modified: 2019-10-25 13:03 UTC (History)
10 users (show)

See Also:
Crash report or crash signature:

ODP with various types of SVG inserted LOv4312 (1.66 MB, application/vnd.oasis.opendocument.presentation)
2014-09-14 10:21 UTC, Owen Genat (retired)
.odp file to reproduce the problem (9.58 MB, application/vnd.oasis.opendocument.presentation)
2016-11-08 12:06 UTC, Frederic Parrenin
Bibisect log (3.58 KB, text/plain)
2017-11-04 20:39 UTC, Telesto
Callgrind output from master (1.31 MB, application/x-xz)
2019-02-05 11:43 UTC, Buovjaga
Example file (253.96 KB, application/vnd.oasis.opendocument.text)
2019-02-05 13:43 UTC, Telesto

Note You need to log in before you can comment on or make changes to this bug.
Description Joel Madero 2014-09-03 08:27:19 UTC
Steps to Reproduce:

Insert a svg into presentation
Insert a new slide
Go back to previous slide

Observed: SVG loads quite slowly (several seconds)
Expected: Images should load immediately (or nearly that)

Set to:
minor - can slow down professional work but not by much
Low - not a very serious issue, default seems fine
Comment 1 Owen Genat (retired) 2014-09-14 10:21:59 UTC
Created attachment 106250 [details]
ODP with various types of SVG inserted LOv4312

(In reply to comment #0)
> Insert a svg into presentation

What type of SVG? In which application was the SVG created? In the attached example only the SVG prepared in Adobe Illustrator loads slowly under GNU/Linux using v4.3.1.2. I admit it is not a good control test, as we need the same graphic saved by different SVG editing applications. The Illustrator one is likely the most complex and can be obtained here:

According to the W3C validator it contains 60 errors (mainly undefined elements and attributes), so the slow rendering may not entirely be the fault of LO.
Comment 2 steve -_- 2014-10-28 01:01:33 UTC
Confirming LO OSX 10.10.

Navigating the slides on the test document is everything but fluent. Thus confirmed, OS  > ALL and NEW.
Comment 3 V Stuart Foote 2015-10-19 14:18:50 UTC
*** Bug 94855 has been marked as a duplicate of this bug. ***
Comment 4 V Stuart Foote 2015-10-19 14:49:12 UTC
*** Bug 89728 has been marked as a duplicate of this bug. ***
Comment 5 V Stuart Foote 2015-10-19 15:13:33 UTC
add attachment 113760 [details] (from dupe bug 89728 ) to an Impress document, copy the slide, then "break" the SVG on each. Run a slide show... get a coffee.

Do the same, but don't "break" the SVG apart--slow still, but not glacial.

So, it seems like SVG on Impress slides have to be managed. Can be done by preparing content in Draw and then exporting to BMP from there for inclusion in a presentation. Or, seems like something more is needed within Impress in preparing the slides for presentation mode--a preprocessor to do the conversion to BMP--and not render on the fly.
Comment 6 Frederic Parrenin 2015-10-21 10:23:13 UTC
A related problem is that LO waits for a slide to be rendered before it is capable of moving to the next slide.
It would be better to have an asynchronous mechanism, where one can always change the slide and then if one waits long enough it is rendered.
That would make it easier and quicker to move several slides back or forward.
Comment 7 Joel Madero 2015-10-21 14:43:00 UTC
Please don't add secondary concerns to bug reports. 1 bug per bug report. "A related problem" should be reported separately.
Comment 8 Frederic Parrenin 2015-10-22 15:36:25 UTC
OK, I reported bug 95261.
Comment 9 QA Administrators 2016-11-08 11:26:55 UTC Comment hidden (obsolete)
Comment 10 Frederic Parrenin 2016-11-08 12:06:46 UTC
Created attachment 128564 [details]
.odp file to reproduce the problem

This bug is still present in LO 5.1.
I attach an .odp presentation with many SVGs.
Going from one slide to the other can take 1-2 s.
By comparison, opening the SVGs in an image viewer like eog takes ~0.2s.
So it seems some optimization might be possible here.
Comment 11 Telesto 2017-11-04 20:14:35 UTC
Based on attachment 128564 [details]

Repro with:
Build ID: 06cad1a9a42ea74434f9ed0e4027163d029eb4a1
CPU threads: 4; OS: Windows 6.3; UI render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2017-11-02_23:40:06
Locale: nl-NL (nl_NL); Calc: CL

and with:
Versie (Bouw-id: 7545bee9c2a0782548772a21bc84a9dcc583b89)

but not with:
Build ID: 3215f89-f603614-ab984f2-7348103-1225a5b
Comment 12 Telesto 2017-11-04 20:39:16 UTC
Created attachment 137525 [details]
Bibisect log

There are only 'skip'ped commits left to test.
The first bad commit could be any of:
Comment 13 Xisco Faulí 2018-01-04 09:54:31 UTC
*** Bug 114806 has been marked as a duplicate of this bug. ***
Comment 14 Roman Kuznetsov 2018-06-19 10:41:36 UTC
I opened both files from attach in LibreOffice 6.1 beta 2. 
There is delay when presentation opens, but changing of slide occurs very fast.

I made it on Intel Core i-3 3120M 2,5 GHz with 4Gb of memory (notebook)

My opinion -> WFM
Comment 15 Buovjaga 2018-08-15 17:06:38 UTC
*** Bug 96880 has been marked as a duplicate of this bug. ***
Comment 16 Buovjaga 2019-02-05 07:46:03 UTC
In attachment 106250 [details], the delay is only in slide 4. I was unable to find the delay with attachment 128564 [details].

Arch Linux 64-bit
Build ID: 8fbad2f600cd3ab81e7c1da0e4a2a71ebcac0553
CPU threads: 8; OS: Linux 4.20; UI render: default; VCL: gtk3; 
Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US
Calc: threaded
Built on 31 January 2019
Comment 17 Frederic Parrenin 2019-02-05 09:22:49 UTC
I tested again with my recent dell xps13 with a 4k screen and with LO 6.1.5.
The situation seems to have improved.
The delay is at most a few 0.1 s, for both attachments 106250 and 128564.
Comment 18 Roman Kuznetsov 2019-02-05 11:27:43 UTC Comment hidden (obsolete)
Comment 19 Buovjaga 2019-02-05 11:43:16 UTC
Created attachment 148900 [details]
Callgrind output from master

Took a callgrind of clicking slide 4 of attachment 106250 [details]

Arch Linux 64-bit
Build ID: 5408f0731b9cd8be0e1b7aa5145b825337baad84
CPU threads: 8; OS: Linux 4.20; UI render: default; VCL: gtk3; 
Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US
Calc: threaded
Built on 5 February 2019
Comment 20 Telesto 2019-02-05 13:43:28 UTC
Created attachment 148918 [details]
Example file

Another SVG example with a sluggish experience
Comment 21 Noel Grandin 2019-06-03 14:09:48 UTC
With current master, all of these load in less than 10s on my machine
Comment 22 Buovjaga 2019-06-03 16:20:05 UTC
(In reply to Noel Grandin from comment #21)
> With current master, all of these load in less than 10s on my machine

Sure, but in attachment 106250 [details] all the slides except 4 show their images instantly