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.
*** This bug has been marked as a duplicate of bug 138068 ***
(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
See also: bug 138808
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)
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.
Any change to check out this bug and bug 138068.. There is clearly a or multiple (image) perf issue at the Linux/macOS front
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
(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
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.
(In reply to pieter kristensen from comment #9) > 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. Please copy and paste here the contents of your Help - About by clicking the copy button.
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
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...
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?
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
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
Todd, joshas: if you run a 7.2 appimage, do you still experience the slowness in the scenarios you described: https://libreoffice.soluzioniopen.com/ ?
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.
Thanks for testing. jmsharvey771, Jean-François and Pieter: can you test as well?
I think that bug is seen in7. 2+ with attached sample, as I changed the title.
(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!)
(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.
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 :)
(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
Is this still valid? As far as I can tell this is a duplicate of bug 138068.
I tested with the "sample document" and WOW a am surpised! My Neon User Edition LO 7.2.2.2 scrolls flawlessly. No problem AT ALL.
(In reply to Luboš Luňák from comment #24) > Is this still valid? As far as I can tell this is a duplicate of bug 138068. We have to wait for Jean-François's test result.
(In reply to Buovjaga from comment #26) > (In reply to Luboš Luňák from comment #24) > > Is this still valid? As far as I can tell this is a duplicate of bug 138068. > > We have to wait for Jean-François's test result. Sorry, he already tested in comment 22 that the fix had no effect.
I've tested this now too, with version 7.3.1.3 as a flatpak from Flathub, and also version 7.0.6.2, and much to my surprise, the issue is gone not only with 7.3.x but also with that older 7.0.6.2, whereas with 7.0.4.x and earlier it was a problem. I don't know what crazy optimizations happened since between 7.0.4.x and 7.0.6.x (or newer versions) but unless it's "just luck" while testing right now, it seems to have really made a huge difference...
(In reply to Jean-François Fortin Tam from comment #28) > I've tested this now too, with version 7.3.1.3 as a flatpak from Flathub, > and also version 7.0.6.2, and much to my surprise, the issue is gone not > only with 7.3.x but also with that older 7.0.6.2, whereas with 7.0.4.x and > earlier it was a problem. > > I don't know what crazy optimizations happened since between 7.0.4.x and > 7.0.6.x (or newer versions) but unless it's "just luck" while testing right > now, it seems to have really made a huge difference... Ok, then I think we can close as duplicate of bug 138068 because it had landed in 7.0.5. *** This bug has been marked as a duplicate of bug 138068 ***