Created attachment 121707 [details] An SVG file that slows Writer down Create a new empty Writer document. Insert->Image choose the attached SVG file Insertion is somewhat long (longer than i feel it should be), and Writer will stutter when scrolling the document past the inserted drawing. Inserting adding text after the inserted drawing will also be slow until the next page is reached. Note that the SVG file only has a bunch of intersecting lines - no complex polygons or patterns (unlike bug 82214). This is confirmed for master~2016-01-04_02.00.52_LibreOfficeDev_5.2.0.0.alpha0_Win_x86_en-US_de_ar_ja_ru_qtz.msi Official 5.0.4.2 x86_64 works even slower. As usual, Draw handles importing this file much better, although Draw also ignores clip regions, while Writer does not (tried to make a version of this SVG file with no clip regions, still slow).
Confirmed, but might still be considered a duplicate report. There is also bug 58420 and it concerns Writer as well. Win 7 Pro 64-bit Version: 5.2.0.0.alpha0+ Build ID: b4082bed2de12cd576a06a9f456a71101809f3ed CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2016-01-02_00:47:38 Locale: fi-FI (fi_FI)
Noticed something very alarming: if i scroll down (sloo-o-owly) to the bottom of the page that has the SVG file in question, then click at the bottom to edit the page footer, LO will play the footer button appearance animation (where the blue "Footer (Default Style)" button will fade in). Normally it plays very fast, but in presence of that SVG file it takes a few seconds for each frame to be drawn. That is, LO, for some reason, does a *complete redraw of the whole SVG* every time any kind of redrawing is required. This is particularly unexpected. I thought LO cached drawable objects for performance reasons, i expected it only to re-render when changing zoom level or when editing the object itself. It's not like the SVG itself is animated and requires redrawing every N milliseconds...
Same problem with Libreoffice 5.0.5.2 on an Ubuntu 15.10 box. Scrolling is very slow. This is particularly annoying when dealing with a document that includes hundreds of SVG images of LaTeX equations (entered using the TexMaths extension). Some people use TexMaths to write their thesis and complain about this slowness...
I can confirm this bug with the given SVG file. However, something strange is that for most SVG files, libreoffice doesn't complain at all.
Created attachment 124037 [details] A libreoffice file with inserted svg objects, that doesn't slow down libreoffice writer This libreoffice file is not buggy at all, while the first .SVG file is slowing libreoffice to death.
I confirm this. I was just about to file a report when I was suggested this ticket. I don't remember this being an issue in version 5.0.x of Writer, as using that version I managed to insert the SVG and work with the document with no problem.
5.2.0.4 is faster than 5.1.x.x, but not fast enough. From usability point of view, scrolling lag must not exceed, like, 0.5 second on slow machines (and my machine is far from slow), otherwise user doesn't perceive the UI as responsive. As i've said, 5.2 improved the performance, but it could be a case that no matter how much performance you squeeze out of that code, it would remain fundamentally slower than rendering other parts of the document. Thus, on slower machines, or when working with more complex SVG files, it would still take more than half a second to re-render while scrolling. Therefore, maybe the solution is not to make it draw faster, but to ensure that LO is not being held up while the rendering is taking place? Maybe put the svg rendering into a separate thread? And draw a placeholder while the object is being rendered? Wait for the other thread for N milliseconds. If the other thread doesn't finish by then, just draw a placeholder and go on, then draw the finished piece when it's ready. That way, if rendering ever gets fast enough for smooth scrolling, there won't be a placeholder flickering.
Just another regression due to the introduction of the new SVG implementation introduced in 4.0. This are smooth in 3.6.7. @Xisco: Any thoughts on this particular svg?
Can this be related to Bug 87485??
I can confirm this behavior in LibreOffice Writer and *Draw* version 5.2.5.1 on openSUSE Leap 42.2, standard distribution packages. This is seriously annoying as it renders Draw basically unusable even on really fast hardware. How can I help? I'd be willing to test patches. Given the fact that this bug is present both in Writer and Draw, should not it be a bug against the framework rather than Writer?
(In reply to Sebastian Ernst from comment #10) > I can confirm this behavior in LibreOffice Writer and *Draw* version 5.2.5.1 > on openSUSE Leap 42.2, standard distribution packages. > > This is seriously annoying as it renders Draw basically unusable even on > really fast hardware. How can I help? I'd be willing to test patches. > > Given the fact that this bug is present both in Writer and Draw, should not > it be a bug against the framework rather than Writer? I think I will do a callgrind trace of this today: https://wiki.documentfoundation.org/QA/BugReport/Debug_Information#GNU.2FLinux:_How_to_get_a_callgrind_trace If you want to help in general, we have a chronic lack of bug triagers. We could easily welcome 10 new triagers and find work for everyone. Here is the intro: https://wiki.documentfoundation.org/QA/GetInvolved
Created attachment 133438 [details] Callgrind output from 5.5 master Arch Linux 64-bit, KDE Plasma 5 Version: 5.5.0.0.alpha0+ Build ID: f856935db77d2f1eeeb6fd297d09ef4262df8761 CPU threads: 8; OS: Linux 4.10; UI render: default; VCL: gtk3; Locale: fi-FI (fi_FI.UTF-8); Calc: group Built on May 21st 2017
still repro in LibreOffice Writer 6.1 beta 2
There are commits in the 43all Linux bibisect repo, where the image is not rendered. So I only got this poor result: 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!
(In reply to Buovjaga from comment #14) > There are commits in the 43all Linux bibisect repo, where the image is not > rendered. So I only got this poor result: > > 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! Same results for bug 96880 (dupe?)
(In reply to Telesto from comment #15) > (In reply to Buovjaga from comment #14) > > There are commits in the 43all Linux bibisect repo, where the image is not > > rendered. So I only got this poor result: > > > > 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! > > Same results for bug 96880 (dupe?) You meant to say bug 83426, but sure, we should definitely call this a dupe *** This bug has been marked as a duplicate of bug 83426 ***