Bug 155410 - Scrolling is much slower in Writer 7.5 with gtk3 VCL in a document with lots of SVG and PNG images
Summary: Scrolling is much slower in Writer 7.5 with gtk3 VCL in a document with lots ...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.5.0.0 alpha0+
Hardware: All Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:7.6.0 target:7.5.5 target:24.2.0
Keywords: bibisected, bisected, perf, regression
Depends on:
Blocks: GTK3 Exit Scrolling-Performance
  Show dependency treegraph
 
Reported: 2023-05-19 15:30 UTC by Roland Baudin
Modified: 2023-11-06 10:49 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Test document with a lot of SVG and PNG images (5.49 MB, application/vnd.oasis.opendocument.text)
2023-05-19 15:30 UTC, Roland Baudin
Details
Test presentation with a big graphic image (imported from SVG) (74.58 KB, application/vnd.oasis.opendocument.presentation)
2023-11-04 18:20 UTC, Roland Baudin
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Roland Baudin 2023-05-19 15:30:17 UTC
Description:
In Linux with gtk3 VCL, scrolling with PgUp / PgDn in a document that contains a lot of PNG and SVG images is nearly two times slower in Writer 7.5 than in Writer 7.4.



Steps to Reproduce:
1. Open the attached document test_complex_document.odt. Zoom level is set to 140%.

2. Put the cursor at the beginning of the document and push the PgDn key until the whole document is scrolled

3. Measure the duration of the scroll

Actual Results:
Scrolling duration is nearly two times slower in Writer 7.5 than in Writer 7.4.

Expected Results:
The scrolling duration should be the same in both versions.


Reproducible: Always


User Profile Reset: Yes

Additional Info:
Further data:

Scrolling durations:

SAL_USE_VCLPLUGIN=gtk3 /opt/libreoffice7.5/program/swriter => 20 s

SAL_USE_VCLPLUGIN=gtk3 /opt/libreoffice7.4/program/swriter => 12 s


Comparison with qt5 VCL:

SAL_USE_VCLPLUGIN=gtk3 /opt/libreoffice7.5/program/swriter => 7 s

SAL_USE_VCLPLUGIN=gtk3 /opt/libreoffice7.4/program/swriter => 7 s



LibreOffice versions:

Version: 7.5.3.2 (X86_64) / LibreOffice Community
Build ID: 9f56dff12ba03b9acd7730a5a481eea045e468f3
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: fr-FR (fr_FR.UTF-8); UI: en-US
Calc: CL threaded

Version: 7.4.7.2 / LibreOffice Community
Build ID: 723314e595e8007d3cf785c16538505a1c878ca5
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: fr-FR (fr_FR.UTF-8); UI: en-US
Calc: CL


System:

Ubuntu 22.04.2 LTS, 64 bits

Hardware:

Intel® Core™ i7-6700K CPU @ 4.00GHz × 8
RAM 32 GB
NVIDIA Corporation GM204 [GeForce GTX 970]
Monitor resolution 2560 x 1440
Comment 1 Roland Baudin 2023-05-19 15:30:51 UTC
Created attachment 187402 [details]
Test document with a lot of SVG and PNG images
Comment 2 Roland Baudin 2023-05-19 15:32:07 UTC
Sorry, there is a typo in my bug report. The lines with the qt5 VCL should be:

SAL_USE_VCLPLUGIN=qt5 /opt/libreoffice7.5/program/swriter => 7 s

SAL_USE_VCLPLUGIN=qt5 /opt/libreoffice7.4/program/swriter => 7 s
Comment 3 Stéphane Guillou (stragu) 2023-05-19 22:12:56 UTC
I compared:

Version: 7.4.7.2 / LibreOffice Community
Build ID: 723314e595e8007d3cf785c16538505a1c878ca5
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: threaded

with:

Version: 7.5.3.2 (X86_64) / LibreOffice Community
Build ID: 9f56dff12ba03b9acd7730a5a481eea045e468f3
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: threaded

On Ubuntu 20.04 with GNOME 3.36.8 + Wayland.

I got an average of:
- 7.4.7.2: 16 seconds to get to bottom; close LO near-instant (less than a second)
- 7.5.3.2: 19 seconds to get to bottom; close LO very slow (several seconds)

I would call it a clear degradation in performance.
I also tested the gen, kf5 and qt5 VCLs: only gtk3 has that slow exit regression.

Using the the snappy vs very sluggish exit time as a discerning factor, I bibisected the issue with the linux-64-7.5 repo to the first bad commit 6f10bfc3f53a7d88037a32deadcc7f3be94c061e which points to core commit:

commit 8611f6e259b807b4f19c8dc0eab86ca648891ce3
author	Noel Grandin <noel.grandin@collabora.co.uk>	Thu May 27 10:27:46 2021 +0200
committer	Noel Grandin <noel.grandin@collabora.co.uk>	Mon Aug 29 13:44:02 2022 +0200
ref-count SdrObject
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138837

Noel, can you please have a look?
Comment 4 Noel Grandin 2023-05-22 13:44:31 UTC
The scrollng part of this seems to have fixed already in master (not sure when), because master is considerably faster (for me) than 7.4

The exit time is still a problem on master, however.
Comment 5 Stéphane Guillou (stragu) 2023-05-22 13:49:33 UTC
Roland, could you please try a recent master build to see if the scrolling slowness is resolved for your system too?
https://dev-builds.libreoffice.org/daily/master/current.html
Comment 6 Roland Baudin 2023-05-22 17:45:56 UTC
I did the tests (same hardware, zoom level 140%, fresh profile) and I see the same scrolling duration:

SAL_USE_VCLPLUGIN=gtk3 /opt/libreoffice7.5/program/swriter => ~16 s
SAL_USE_VCLPLUGIN=gtk3 /opt/libreofficedev7.6/program/swriter => ~16 s

Slow exit in both cases.

(this is slightly different from my previous results, but I've already noticed that the scrolling duration can vary).

Usint qt5 backend, I get:

SAL_USE_VCLPLUGIN=qt5 /opt/libreoffice7.5/program/swriter => ~6 s
SAL_USE_VCLPLUGIN=qt5 /opt/libreofficedev7.6/program/swriter => ~6 s

Normal (fast) exit in both cases.
Comment 7 Commit Notification 2023-05-23 12:34:50 UTC
Noel Grandin committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/4fac9a110961f19006c3041be0c4b920a5eafe7b

tdf#155410 speedup shutdown when document has lots of images

It will be available in 7.6.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 8 Commit Notification 2023-05-23 12:36:53 UTC
Noel Grandin committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/8de6e211b760761f1f80b2a7371a5f6b640ab14e

tdf#155410 move some layer/object visibility computation inside SdrObject

It will be available in 7.6.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 9 Commit Notification 2023-05-24 06:11:27 UTC
Noel Grandin committed a patch related to this issue.
It has been pushed to "libreoffice-7-5":

https://git.libreoffice.org/core/commit/96be41d5ba28e1d3b361efdad5e8cad9d9d0fe77

tdf#155410 speedup shutdown when document has lots of images

It will be available in 7.5.5.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 10 Noel Grandin 2023-05-24 06:19:45 UTC
I have done what I can here, but unfortunately I'm working blind because I cannot repro this, because my graphics card is too old to get the skia stuff to kick in, so all I see on the performance profile is the cairo graphics fallback paths.
Comment 11 Roland Baudin 2023-05-24 07:52:32 UTC
OK, thanks, I'll test the build when it will be available (however, I'm in vacation for one week with no Linux box, so please be patient).

However, concerning the remark of Noel, I thought that skia was not used in Linux, am I wrong?
Comment 12 Roland Baudin 2023-06-01 07:47:45 UTC
Hi,

I tested with a dev version (31/05/2023) and the scrolling duration is still slower than in LO 7.4.x (only with gtk3 VCL).

But now, the close issue has disappeared. That's good.
Comment 13 Roland Baudin 2023-06-11 15:20:42 UTC
The problem is still there in version 7.5.4.2 (slow scrolling with gtk rendering and slow document close).

Perhaps the patch was not applied to this version?
Comment 14 Stéphane Guillou (stragu) 2023-09-15 10:59:17 UTC
(In reply to Roland Baudin from comment #13)
> The problem is still there in version 7.5.4.2 (slow scrolling with gtk
> rendering and slow document close).
> 
> Perhaps the patch was not applied to this version?

If you look at the commits above, you will see which versions they are going to. Only one patch made it into 7.5.6, and two patches in 7.6.
I'd recommend updating to 7.6 to test.
https://www.libreoffice.org/download/download-libreoffice/
Thank you!
Comment 15 Roland Baudin 2023-09-16 10:04:56 UTC
OK, thanks.

I did the same tests as above with LibreOffice 7.6.1.2, in the same conditions, and got exactly the same results, that is:

SAL_USE_VCLPLUGIN=gtk3 /opt/libreoffice7.6/program/swriter => 20 s

So scrolling in LO 7.6 is slower than in LO 7.4.

Note that exit is fast as expected.
Comment 16 Commit Notification 2023-10-18 10:11:59 UTC
Noel Grandin committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/0280a9ef0d93bb2c8ec713b6dc36b77962b57e99

tdf#155410 shave 1% cost off SdrGroup::GetLayer

It will be available in 24.2.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 17 Commit Notification 2023-10-19 13:21:54 UTC
Noel Grandin committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/f5c4635c8bbd27b06a81bfa8d75f986994065310

tdf#155410 small optimisation

It will be available in 24.2.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 18 M. Knepper 2023-10-19 17:44:28 UTC
I'll give this a test. I'm having severe CPU spikes and laggy performance when trying to scroll just about anything but this only seems to happen at 4k. Downloading build now.
Comment 19 Roland Baudin 2023-11-04 18:02:26 UTC
OK, thanks for the patch!

I did another test: same hardware, same document, fresh LO profiles.

Here are the results:

Scrolling time:

SAL_USE_VCLPLUGIN=gtk3 /opt/libreoffice7.4/program/swriter => 13.5 s

SAL_USE_VCLPLUGIN=gtk3 /opt/libreoffice7.5/program/swriter => 16.5 s

SAL_USE_VCLPLUGIN=gtk3 /opt/libreoffice7.6/program/swriter => 16.5 s

SAL_USE_VCLPLUGIN=gtk3 /opt/libreofficedev24.2/program/swriter => 13.5 s


Comparison with qt5:

SAL_USE_VCLPLUGIN=qt5 /opt/libreoffice7.4/program/swriter => 7.5 s

SAL_USE_VCLPLUGIN=qt5 /opt/libreoffice7.5/program/swriter => 7 s

SAL_USE_VCLPLUGIN=qt5 /opt/libreoffice7.6/program/swriter => 7 s

SAL_USE_VCLPLUGIN=qt5 /opt/libreofficedev24.2/program/swriter => 6.5 s


So as you can see, the patch from LO dev24.2 has clearly reduced the scrolling time and now the performances are the same as in LO 7.4. Well done!


Here are the LO builds I used (in Ubuntu 22.04.3):


For gtk3:


Version: 7.4.7.2 / LibreOffice Community
Build ID: 723314e595e8007d3cf785c16538505a1c878ca5
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: fr-FR (fr_FR.UTF-8); UI: en-US
Calc: CL

Version: 7.5.8.2 (X86_64) / LibreOffice Community
Build ID: f718d63693263970429a68f568db6046aaa9df01
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: fr-FR (fr_FR.UTF-8); UI: en-US
Calc: CL threaded

Version: 7.6.2.1 (X86_64) / LibreOffice Community
Build ID: 56f7684011345957bbf33a7ee678afaf4d2ba333
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: fr-FR (fr_FR.UTF-8); UI: en-US
Calc: CL threaded

Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: fc1ba4d17fd71656205697a6cf19432037e4a9d6
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: fr-FR (fr_FR.UTF-8); UI: en-US
Calc: CL threaded


For qt5:

Version: 7.4.7.2 / LibreOffice Community
Build ID: 723314e595e8007d3cf785c16538505a1c878ca5
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: qt5 (qfont+xcb)
Locale: fr-FR (fr_FR.UTF-8); UI: en-US
Calc: CL

Version: 7.5.8.2 (X86_64) / LibreOffice Community
Build ID: f718d63693263970429a68f568db6046aaa9df01
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: qt5 (cairo+xcb)
Locale: fr-FR (fr_FR.UTF-8); UI: en-US
Calc: CL threaded

Version: 7.6.2.1 (X86_64) / LibreOffice Community
Build ID: 56f7684011345957bbf33a7ee678afaf4d2ba333
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: qt5 (cairo+xcb)
Locale: fr-FR (fr_FR.UTF-8); UI: en-US
Calc: CL threaded

Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: fc1ba4d17fd71656205697a6cf19432037e4a9d6
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: qt5 (cairo+xcb)
Locale: fr-FR (fr_FR.UTF-8); UI: en-US
Calc: CL threaded
Comment 20 Roland Baudin 2023-11-04 18:20:06 UTC
Created attachment 190650 [details]
Test presentation with a big graphic image (imported from SVG)
Comment 21 Roland Baudin 2023-11-04 18:29:51 UTC
I did another test with another document (test_complex_graphic.odp). This one contains a big (silly) equation produced by TexMaths.

With gtk3, selecting the graphic image with the mouse takes a few seconds, while it's much faster with qt5.

Here are the selection times with gtk3:

SAL_USE_VCLPLUGIN=grk3 /opt/libreoffice7.4/program/simpress => 1.5 s

SAL_USE_VCLPLUGIN=gtk3 /opt/libreoffice7.5/program/simpress => 8 s

SAL_USE_VCLPLUGIN=gtk3 /opt/libreoffice7.6/program/simpress => 8 s

SAL_USE_VCLPLUGIN=gtk3 /opt/libreofficedev24.2/program/simpress => 6 s


And with qt5:

SAL_USE_VCLPLUGIN=qt5 /opt/libreoffice7.4/program/simpress => < 1 s

SAL_USE_VCLPLUGIN=qt5 /opt/libreoffice7.5/program/simpress => < 1 s

SAL_USE_VCLPLUGIN=qt5 /opt/libreoffice7.6/program/simpress => < 1 s

SAL_USE_VCLPLUGIN=qt5 /opt/libreofficedev24.2/program/simpress => < 1 s


So once again, we can see that gtk3 rendering is much slower than qt5 (especially in LO 7.5 and 7.6). The patch in LO dev24.2 improves things a bit, but not much.

Note that in Inkscape, selecting the big graphic image is fast, so I think the problem does not come from gtk3 itself, but probably from the gtk3 rendering implemented in LibreOffice...


I don't recall here the LO versions I used, they are the same as in my previous comment.