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
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.
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.
*** Bug 94855 has been marked as a duplicate of this bug. ***
*** Bug 89728 has been marked as a duplicate of this bug. ***
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.
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.
Please don't add secondary concerns to bug reports. 1 bug per bug report. "A related problem" should be reported separately.
OK, I reported bug 95261.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.1.6 or 5.2.3 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20161108
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.
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
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
*** Bug 114806 has been marked as a duplicate of this bug. ***
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
*** Bug 96880 has been marked as a duplicate of this bug. ***
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
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.
(In reply to Frederic Parrenin from comment #17) > 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. Ok, let's close it as WFM
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
Created attachment 148918 [details] Example file Another SVG example with a sluggish experience
With current master, all of these load in less than 10s on my machine
(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
(In reply to Buovjaga from comment #22) > (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 Possibly it's an another problem? There is a delay around 1 sec, but I don't think it's "Load Slowly"
Ok, I guess the delay is acceptable. 7 years ago the delay was "several seconds", but now we have faster computers.