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)
Version:
(earliest affected)
4.0.0.3 release
Hardware: All All
: low minor
Assignee: Not Assigned
URL:
Whiteboard:
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-02-05 13:43 UTC (History)
10 users (show)

See Also:
Crash report or crash signature:


Attachments
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)
Details
.odp file to reproduce the problem (9.58 MB, application/vnd.oasis.opendocument.presentation)
2016-11-08 12:06 UTC, Frederic Parrenin
Details
Bibisect log (3.58 KB, text/plain)
2017-11-04 20:39 UTC, Telesto
Details
Callgrind output from master (1.31 MB, application/x-xz)
2019-02-05 11:43 UTC, Buovjaga
Details
Example file (253.96 KB, application/vnd.oasis.opendocument.text)
2019-02-05 13:43 UTC, Telesto
Details

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:

http://en.wikipedia.org/wiki/File:NuclearPore.svg

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 4.3.3.1 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:
Version: 6.0.0.0.alpha1+
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 4.0.0.3 (Bouw-id: 7545bee9c2a0782548772a21bc84a9dcc583b89)

but not with:
LibreOffice 3.5.7.2 
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:
7fd8bdb3b18f50ea0adbc0a5e611f6a844b23189
a67b874d60de1f1a44bef57a53a7b8a84db0ba58
46f9a799a00ba869957d7aa7650cae7fd2501394
d73160956706b297f4a7043d35e229f2e8566d5f
183a576d94de9a9439d580c8b81f335ab57cdbdc
221bf5c0db153e24c67ff29fe614af7cc010a356
79e02001f27d33b3b478324ab6fba5683413b4d9
e5973caebe5b9637f93a4da008d76b33b9d5ff6a
1f14665c5624bc7a502738aa8f4f2bd70a211e72
ba6eb41acb8df58f3009920f8ab8b32a3e1b764e
99f63b2b53c0e22baac045d54f502508d7150fef
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
Version: 6.3.0.0.alpha0+
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
Version: 6.3.0.0.alpha0+
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