Bug 139068 - Extremely slow scrolling in Writer when images are enabled in a document (KDE, GTK3, GDI worse, SKIA better)
Summary: Extremely slow scrolling in Writer when images are enabled in a document (KD...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: perf
Depends on:
Blocks: Smooth-Scroll Images
  Show dependency treegraph
 
Reported: 2020-12-19 15:56 UTC by Jean-François Fortin Tam
Modified: 2021-05-06 18:35 UTC (History)
11 users (show)

See Also:
Crash report or crash signature:


Attachments
sample document (192.39 KB, application/vnd.oasis.opendocument.text)
2020-12-19 15:56 UTC, Jean-François Fortin Tam
Details
sample document - hardcore edition (9.63 MB, application/vnd.oasis.opendocument.text)
2020-12-25 17:23 UTC, Jean-François Fortin Tam
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jean-François Fortin Tam 2020-12-19 15:56:15 UTC
Created attachment 168332 [details]
sample document

A fork / spiritual successor to bug #87485, with a very simple and precise testcase I'm attaching here.

Grab this standard testing document I've built for the purposes of this bug report, then scroll its pages and down on Linux (I'm running GNOME on Xorg on Fedora 33 with open source radeon graphics and an Intel Xeon, but this happens on all of my machines).

You will notice extreme slowness (i.e. the equivalent of 1 to 5 frames per second) when scrolling up and down with the mouse wheel (or click-dragging the scrollbar), even if you have "smooth scrolling" disabled, even if you're not using a touchpad.

Then go to the "View" menu and turning off "Images and charts" makes it butter-smooth and snappy. In fact, this is what I end up having to do for any big documents.

This issue has been tested on LibreOffice 7.0.4.2, but it's been there forever, with every LibreOffice version I've tested in the past decade or so (and GO-Oo/OOo before that, I suspect).

As I built this document specifically for testing this, if you have a performance test suite and would like to include that document in it, I would be delighted for it to serve that purpose. I kept it reasonably simple (no fancy wrapping, columns, drop caps, comments-in-the-margin, etc.) to facilitate debugging.
Comment 1 Telesto 2020-12-19 16:16:10 UTC Comment hidden (obsolete)
Comment 2 Telesto 2020-12-19 16:19:41 UTC
(In reply to Telesto from comment #1)
> 
> *** This bug has been marked as a duplicate of bug 138068 ***

FWIW: there is tremendous perf flaw in 7.0 branch.. If your statement is correct this might not be a duplicate but something else.. however currently masked by a different perf bug.. So worth a re-check at the point the other issue is solved
Comment 3 Telesto 2020-12-19 16:20:12 UTC Comment hidden (obsolete)
Comment 4 Jean-François Fortin Tam 2020-12-25 17:23:13 UTC
Created attachment 168485 [details]
sample document - hardcore edition

This document with bigger images and a slightly more complex arrangement (with paragraph wrapping) demonstrates the performance problem not only on LOo 7.x, but also on 6.3.6.2 and previous versions.

The new images are taken from unsplash.com and are royalty-free as I understand it (see https://unsplash.com/license)
Comment 5 Jean-François Fortin Tam 2020-12-25 17:25:49 UTC
Reopening/de-duplicating because (as I mentioned) this bug has affected every previous version of LibreOffice I've tried, it is not specific to 7.0; however, I realize now that the sample I previously attached was not "hardcore" enough to make the bug very obvious on versions other than 7.0, so I've attached a new sample that makes it so.
Comment 6 Telesto 2021-01-02 13:18:36 UTC Comment hidden (obsolete)
Comment 7 Telesto 2021-01-03 11:13:43 UTC
FWIW: It's not great but OK with gen
Version: 6.4.5.0.0+
Build ID: 8871f81f218dd49de27d528e54a515d1648d3554
CPU threads: 2; OS: Linux 5.3; UI render: default; VCL: x11; 
Locale: en-US (en_US.UTF-8); UI-Language: en-US
Calc: threaded

but regressed even more with  -> bug 138068.

Scrolling is pretty smooth with GTK3 
Version: 6.4.5.0.0+
Build ID: 8871f81f218dd49de27d528e54a515d1648d3554
CPU threads: 2; OS: Linux 5.3; UI render: default; VCL: gtk3; 
Locale: en-US (en_US.UTF-8); UI-Language: en-US
Calc: threaded

Except hammering the CPU (so images probably re-rendered over and over). Which has been solved for Windows with Skia.

but using 
Version: 7.1.0.0.beta1+
Build ID: e2cffcf55b04838abc7497f6c18518c7600b670b
CPU threads: 2; OS: Linux 5.3; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

is really slow again -> bug 138068
Comment 8 Telesto 2021-01-03 11:31:28 UTC
(In reply to Telesto from comment #7)
> but using 
> Version: 7.1.0.0.beta1+
> Build ID: e2cffcf55b04838abc7497f6c18518c7600b670b
> CPU threads: 2; OS: Linux 5.3; UI render: default; VCL: gtk3
> Locale: en-US (en_US.UTF-8); UI: en-US
> Calc: threaded
> 
> is really slow again -> bug 138068

Me being wrong there, it's even another (new) bug: 139385
Comment 9 pieter kristensen 2021-01-18 11:20:43 UTC
I can reproduce this bug using the sample document in the same version of LO both in Windows 10 and in Neon KDE.
Extreme slowness.
Comment 10 Buovjaga 2021-01-18 11:25:17 UTC Comment hidden (obsolete)
Comment 11 pieter kristensen 2021-01-18 15:23:51 UTC
Version: 7.0.4.2
Build ID: 00(Build:2)
CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: kf5
Locale: nl-NL (nl_NL.UTF-8); GI: nl-NL
Ubuntu package version: 1:7.0.4~rc2-0ubuntu0.20.04.2
Calc: threaded
Comment 12 pieter kristensen 2021-01-18 16:12:43 UTC
I see: Hardware Linux All
But in my opinion you might as well add 
Window 10 64 bit.
Windows 10 also scrolls very slow in the sample document.
It's no difference...
Comment 13 jmsharvey771 2021-02-03 16:07:45 UTC
One thing I've noticed is that this mostly happens with large images that need to be scaled down to fit. With the sample document, scrolling would totally pin one CPU core. When I have a very small image, this doesn't happen and CPU usage remains low. I've also tried force-enabling Skia, which didn't have any effect. How does Libreoffice handle scaling images?
Comment 14 Todd Lewis 2021-02-25 04:02:39 UTC
I'm seeing the same thing. Writer is all but unusable with images.
Fedora 33
Version: 7.0.4.2
Build ID: 00(Build:2)
CPU threads: 12; OS: Linux 5.10; UI render: default; VCL: gtk3
Locale: en-US (en_US.utf8); UI: en-US
Calc: threaded
Comment 15 joshas 2021-02-27 10:46:17 UTC
I have a 20 page document with one or two high resolution photos embedded on almost each page. Now I cannot work on this document, because every time there is a photo visible on screen it lags during scroll.
Tested on Fedora 33.

On current version of LibreOffice Writer scrolling lags every time there is a photo visible on screen. Feels like photo is being re-rendered each time on scroll. Same on old i3 laptop with integrated GPU, and on Ryzen 3 desktop with Radeon GPU. Running in "Safe Mode" or turning off "Hardware Acceleration" does not improve performance.
*Version Information*
Version: 7.0.4.2
Build ID: 00(Build:2)
CPU threads: 4; OS: Linux 5.10; UI render: default; VCL: gtk3
Locale: lt-LT (en_US.UTF-8); UI: en-US
Calc: threaded

Reverted to older version of LibreOffice and it performs much better. While it lags first time image enters the screen, scrolling is smooth later and I actually can work on the document. I get the feeling that images are rendered and cached for some time, because I can scroll few pages up and down without any lag. Scrolling fully from bottom to top causes minor slow downs, as some images were removed from cache and have to be rendered again.
*Version Information*
Version: 7.0.1.2
Build ID: 00(Build:2)
CPU threads: 4; OS: Linux 5.10; UI render: default; VCL: gtk3
Locale: lt-LT (en_US.UTF-8); UI: en-US
Calc: threaded
Comment 16 Buovjaga 2021-02-27 11:37:15 UTC
Todd, joshas: if you run a 7.2 appimage, do you still experience the slowness in the scenarios you described: https://libreoffice.soluzioniopen.com/ ?
Comment 17 joshas 2021-02-27 13:06:17 UTC
Tested the same document on LibreOfficeDev-7.2.0.0.alpha0_2021-02-15-x86_64.AppImage and it seems to be working as good as 7.0.1.2, with minimal lag when new image appears.
Comment 18 Buovjaga 2021-02-27 13:29:40 UTC
Thanks for testing.

jmsharvey771, Jean-François and Pieter: can you test as well?
Comment 19 Timur 2021-02-27 13:47:08 UTC Comment hidden (obsolete)
Comment 20 Todd Lewis 2021-02-27 15:49:42 UTC
(In reply to Buovjaga from comment #16)
> Todd, joshas: if you run a 7.2 appimage, do you still experience the
> slowness in the scenarios you described:
> https://libreoffice.soluzioniopen.com/ ?

LibreOfficeDev-7.2.0.0.alpha0_2021-02-15-x86_64.AppImage does not exhibit this slowness problem. Within that appimage, Writer is as responsive as it used to be.
(Hope returns!)
Comment 21 Timur 2021-02-27 15:52:14 UTC
(In reply to Timur from comment #19)
> I think that bug is seen in7. 2+ with attached sample, as I changed the
> title.

Meaning that test should be done both with and without Skia in Options - View.
Comment 22 Jean-François Fortin Tam 2021-02-27 16:10:48 UTC
Todd & Joshas, what you're seeing is probably the 7.0 regression described in bug #138068. That bug being fixed in 7.2 does not solve the issue I have reported above, which predates it. 

My bug report here is about the test case of heavy/high-resolution images; please use the sample testing document I have attached above as it lets you see the problem on any version, old or new, not just 7.0/7.1. At least it does on my end.

Just to be sure "in any case", I have tested the 7.2 alpha appimage on a spare testing machine here; indeed the bug persists, whether with the default settings or when setting UseSkia and ForceSkia to True in the options dialog's "Advanced > Open Expert Configuration".

Unless someone like Luboš or Armin look specifically at optimizing for this issue here, we cannot assume it is fixed by the changes meant for bug #138068.

Just stating this to avoid confusion between the two tickets :)
Comment 23 Todd Lewis 2021-02-27 18:33:00 UTC
(In reply to Jean-François Fortin Tam from comment #22)
> Todd & Joshas, what you're seeing is probably the 7.0 regression described
> in bug #138068. That bug being fixed in 7.2 does not solve the issue I have
> reported above, which predates it. 
> 
> My bug report here is about the test case of heavy/high-resolution images;
> [...]

You are correct.

Although the attached sample document talks about slowed scrolling, the problem to me at least is much more strikingly demonstrated by trying to simply add garbage text. With "View -> Images and Charts" uncheck, it's instantaneous. With "View -> Images and Charts" checked, it can take as long as 10 seconds before the first typed characters start to appear in the document. (And scrolling is slow, as you said.)

Just confirmed this with the attached sample document and both
Version: 7.0.4.2
Build ID: 00(Build:2)
CPU threads: 12; OS: Linux 5.10; UI render: default; VCL: gtk3
Locale: en-US (en_US.utf8); UI: en-US
Calc: threaded

and

Version: 7.2.0.0.alpha0+ / LibreOffice Community
Build ID: 41cffc379259fec626a282ca243a9750d96d1c63
CPU threads: 12; OS: Linux 5.10; UI render: default; VCL: gtk3
Locale: en-US (en_US.utf8); UI: en-US
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2021-02-15_20:07:52
Calc: threaded