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
Created attachment 187402 [details] Test document with a lot of SVG and PNG images
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
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?
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.
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
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.
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.
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.
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.
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.
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?
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.
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?
(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!
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.
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.
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.
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.
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
Created attachment 190650 [details] Test presentation with a big graphic image (imported from SVG)
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.