Created attachment 121707 [details]
An SVG file that slows Writer down
Create a new empty Writer document.
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
Official 126.96.36.199 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: 188.8.131.52.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 184.108.40.206 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.
220.127.116.11 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 18.104.22.168 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 22.214.171.124
> 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
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:
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:
> 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 ***