Download it now!
Bug 96880 - Slow page scrolling when an SVG object is in view
Summary: Slow page scrolling when an SVG object is in view
Status: RESOLVED DUPLICATE of bug 83426
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.0.6.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, filter:svg, haveBacktrace, perf, regression
Depends on:
Blocks: SVG-Import
  Show dependency treegraph
 
Reported: 2016-01-04 05:14 UTC by LRN
Modified: 2018-08-15 17:06 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
An SVG file that slows Writer down (151.40 KB, image/svg+xml)
2016-01-04 05:14 UTC, LRN
Details
A libreoffice file with inserted svg objects, that doesn't slow down libreoffice writer (32.64 KB, application/vnd.oasis.opendocument.text)
2016-04-03 11:54 UTC, David Kremer
Details
Callgrind output from 5.5 master (7.21 MB, application/x-xz)
2017-05-21 17:46 UTC, Buovjaga
Details

Note You need to log in before you can comment on or make changes to this bug.
Description LRN 2016-01-04 05:14:35 UTC
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).
Comment 1 Buovjaga 2016-01-04 13:53:08 UTC
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)
Comment 2 LRN 2016-01-12 07:40:21 UTC
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...
Comment 3 Roland Baudin 2016-04-01 16:32:34 UTC
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...
Comment 4 David Kremer 2016-04-03 11:52:56 UTC
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.
Comment 5 David Kremer 2016-04-03 11:54:19 UTC
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.
Comment 6 Daniel Grigoras 2016-04-14 09:39:59 UTC
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.
Comment 7 LRN 2016-08-03 14:51:58 UTC
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.
Comment 8 Yousuf Philips (jay) (retired) 2016-08-03 15:08:16 UTC
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?
Comment 9 Anass Ahmed 2016-11-19 12:11:46 UTC
Can this be related to Bug 87485??
Comment 10 Sebastian Ernst 2017-05-21 10:32:22 UTC
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?
Comment 11 Buovjaga 2017-05-21 15:33:16 UTC
(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
Comment 12 Buovjaga 2017-05-21 17:46:23 UTC
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
Comment 13 Roman Kuznetsov 2018-06-19 14:56:19 UTC
still repro in LibreOffice Writer 6.1 beta 2
Comment 14 Buovjaga 2018-07-01 16:36:25 UTC
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!
Comment 15 Telesto 2018-08-14 18:25:19 UTC
(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?)
Comment 16 Buovjaga 2018-08-15 17:06:38 UTC
(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 ***