Bug 152911 - VIEWING - High CPU and lag when scrolling on Wayland with modified display scale (KF5)
Summary: VIEWING - High CPU and lag when scrolling on Wayland with modified display sc...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.3.7.2 release
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: perf
Depends on:
Blocks: Wayland KDE Crash Scrolling-Performance
  Show dependency treegraph
 
Reported: 2023-01-07 13:25 UTC by bugs
Modified: 2024-02-01 08:24 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Sample document with many words (115.75 KB, application/vnd.oasis.opendocument.text)
2024-02-01 07:33 UTC, Michael Weghorn
Details
Hotspot flamegraph of scrolling using scrollbar w/ qt6 on Wayland (2.81 MB, image/svg+xml)
2024-02-01 08:09 UTC, Michael Weghorn
Details

Note You need to log in before you can comment on or make changes to this bug.
Description bugs 2023-01-07 13:25:50 UTC
Description:
When using KDE Wayland on a laptop with an AMD integrated GPU, I get some high CPU spikes and massive lag when i scroll through a document. Large documents (tens of thousands of words, zero images) are near-unusable, but this is noticeable even on an empty one-page document. On an X11 session, scrolling is perfectly smooth.

Steps to Reproduce:
1. Start a KDE Wayland session
2. Open LibreOffice Writer
3. Scroll

Actual Results:
Choppy scrolling and high CPU usage

Expected Results:
Smooth scrolling, like in X11


Reproducible: Always


User Profile Reset: No

Additional Info:
This is on LO 7.4.3.2, kf5 (cairo+wayland) Linux 6.0 (Fedora 37). I have smooth scrolling disabled and hardware acceleration enabled (toggling any of these settings makes no difference). I do use fractional scaling on Wayland, but then again it doesn't make a difference, the only factor that makes it not lag seems to be not using Wayland at all. Starting LO in Safe Mode does not make a difference either.
Comment 1 Stéphane Guillou (stragu) 2023-01-11 08:18:58 UTC
Could not reproduce with:

Version: 7.4.3.2 / LibreOffice Community
Build ID: 1048a8393ae2eeec98dff31b5c133c5f1d08b890
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: kf5 (cairo+wayland)
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: threaded

Integrated GPU: Intel Corporation UHD Graphics 620 (rev 07)

Could you maybe share an example document where the lag is clearly visible, for others to test?
Comment 2 bugs 2023-01-11 20:07:47 UTC
Upon further testing the problem does seem to be fractional scaling, since setting scaling to 1x and only then opening a new instance of LO has no issues. Since KDE renders at double the resolution to achieve fractional scaling, it may just be my computer not being able to render LO scrolling at 4K (AMD Ryzen 5 laptop). The Flatpak version runs better (still choppy), the non-Flatpak skips all the graphics tests so I may be missing something graphics related as well.

I'll leave it up to you whether to close this one. Thanks!
Comment 3 QA Administrators 2023-01-12 03:21:26 UTC Comment hidden (obsolete)
Comment 4 Stéphane Guillou (stragu) 2023-01-12 09:57:42 UTC
I could actually reproduce some very sluggish scrolling. On Ubuntu 20.04 with GNOME + Wayland, all my displays at 200% scaling, starting LO with:

And then changing all my displays' scaling back to 100% (with LO still open), I end up with extremely choppy scrolling with the mousewheel, and even more so by dragging the scrollbar: it struggles so much that it hangs, and I managed to make it crash(?) with the console message:

   The Wayland connection broke. Did the Wayland compositor die?

(The LO window disappears, but I still had to kill the process in the console.)

Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 92deea6301a02f5530f17263f58402344f82013c
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: kf5 (cairo+wayland)
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: threaded

Not reproducible with GTK3.
Comment 5 Gauthier 2023-08-23 09:55:19 UTC
I can reproduce this bug, both with an AMD integrated GPU and with Intel UHD Graphics 620 and with scaling at 100%.

On wayland scrolling lags and on X11 itś perfectly smooth.

The problem has been there for months, at least since LO 7.5.0 (possibly its always been there). As someone else reported, hen trying "Run Graphics Tests" everything skips on both my AMD and Intel machines on wayland (I haven´t tried the flatpack version).

So I don´t think it has to do with scaling or with AMD.

Version: 7.5.5.2 (X86_64) / LibreOffice Community
Build ID: 50(Build:2)
CPU threads: 12; OS: Linux 6.2; UI render: default; VCL: kf5 (cairo+wayland)
Locale: en-GB (en_GB.UTF-8); UI: en-GB
Ubuntu package version: 4:7.5.5-0ubuntu0.23.04.1
Calc: threaded

Operating System: Kubuntu 23.04 / KDE Neon (based on Ubuntu 22.04)
KDE Plasma Version: 5.27.7
KDE Frameworks Version: 5.109.0
Qt Version: 5.15.8 / 5.15.10
Kernel Version: 6.2.0-27-generic (64-bit)
Graphics Platform: Wayland
Processors: AMD Ryzen 5 PRO 6650U with Radeon Graphics / Intel i5-8350U
Memory: 30.7 GiB of RAM
Graphics Processor: AMD Radeon Graphics / Intel UHD Graphics 620
Comment 6 Gauthier 2023-08-23 11:55:16 UTC
Update:
=======
using VCL: gtk3 brings back smooth scrolling on wayland. 

So the issue seem to be with the kf5 vcl plugin or actually with Qt.

Can anyone reproduce / confirm??
Comment 7 Gauthier 2023-08-23 12:20:22 UTC
Another update (and I promise after that I'll stop spamming this bug report):
===============

While I do not use fractional scaling, I use two screens. 

If I unplug my external screen I get pretty smooth scrolling again on wayland with the kf5 vcl (it somewhat does not quite feel as smooth as in X11 or in Wayland with gtk3 vlc but it's definitely hardly noticeable and certainly not bothering).
Comment 8 Dan Dascalescu 2023-11-07 23:28:42 UTC
As a sanity/insanity check, can folks try reproducing when running LO as root?

I see far slower scrolling on the same OS (Fedora 38 now, but saw this with Ubuntu 20 too) - https://bugs.documentfoundation.org/show_bug.cgi?id=153985#c15
Comment 9 Stéphane Guillou (stragu) 2024-02-01 03:23:41 UTC
I can still reproduce in 7.6, in two ways, with or without two displays, and with or without scaling:

(1) With a single display, reducing scaling while LO is open (as in comment 4, but only 1 display)

(2) With two extended display, both at 100% scaling, _when the window spans the two screens_.

Version: 7.6.4.1 (X86_64) / LibreOffice Community
Build: e19e193f88cd6c0525a17fb7a176ed8e6a3e2aa1
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: kf5 (cairo+wayland)
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: threaded

Same with qt5 (cairo+wayland).

Same back in 7.3.7.2.

Michael, wondering if the two methods above give some interesting clues?
Comment 10 Michael Weghorn 2024-02-01 07:33:10 UTC
Created attachment 192315 [details]
Sample document with many words
Comment 11 Michael Weghorn 2024-02-01 07:39:04 UTC
(In reply to Stéphane Guillou (stragu) from comment #9)
> I can still reproduce in 7.6, in two ways, with or without two displays, and
> with or without scaling:
> 
> (1) With a single display, reducing scaling while LO is open (as in comment
> 4, but only 1 display)
> 
> (2) With two extended display, both at 100% scaling, _when the window spans
> the two screens_.


So far, I cannot reproduce on Debian testing (qtbase packages at version 5.15.10+dfsg-6). Both of the scenarios work fine for me when using attachment 192315 [details] as document when testing.

> Same with qt5 (cairo+wayland).
> 
> Same back in 7.3.7.2.
> 
> Michael, wondering if the two methods above give some interesting clues?

Hard to say, since I cannot reproduce locally.
A flamegraph (see [1]) might give clues of where CPU time is spent.

Does this also happen with the qt6 VCL plugin or only with qt5/kf5?
(qt6 plugin is not yet part of TDF-provided packages yet, so would e.g. either need an `--enable-qt6` local build or package libreoffice-qt6 from a Debian-based distro).

[1] https://wiki.documentfoundation.org/Development/How_to_debug/en#Performance_debugging_(perf)


Version: 24.2.0.2 (X86_64) / LibreOffice Community
Build ID: 420(Build:2)
CPU threads: 12; OS: Linux 6.5; UI render: default; VCL: kf5 (cairo+wayland)
Locale: en-GB (en_GB.UTF-8); UI: en-GB
Debian package version: 4:24.2.0~rc2-2
Calc: threaded
Comment 12 Michael Weghorn 2024-02-01 08:09:07 UTC
Created attachment 192316 [details]
Hotspot flamegraph of scrolling using scrollbar w/ qt6 on Wayland
Comment 13 Michael Weghorn 2024-02-01 08:18:20 UTC
(In reply to Michael Weghorn from comment #11)
> So far, I cannot reproduce on Debian testing (qtbase packages at version
> 5.15.10+dfsg-6). Both of the scenarios work fine for me when using
> attachment 192315 [details] as document when testing.

OK, I can somewhat reproduce something now:

1) open attachment 192315 [details] with kf5/qt5/qt6 on Wayland
2) move through the document by dragging the handle in the vertical scrollbar

There's a delay to update the view and it's sometimes stuck for maybe 1-2 seconds before the view updates.

It's smooth when forcing the use of the x11 Qt backend (running via XWayland) by setting env variable QT_QPA_PLATFORM=xcb.

Answering my own questions:

> A flamegraph (see [1]) might give clues of where CPU time is spent.

attachment 192316 [details] is a flamegraph with qt6, using local LO and qtbase debug builds. It shows that most time seems to be spent in rendering the document, triggered by the scrolling.
Maybe something is different in how Qt handles the mouse events on Wayland as compared to X11 (s. e.g. the QtWidget::mouseMoveEvent in the flamegraph), like maybe events are triggered more often now, so re-rendering the doc happens more often? (Just a wild guess.)
This would need further analysis to be able to say anything specific and I don't see any obviously wrong in the flamegraph by itself otherwise, I'd expect the call stack to generally be the same with X11.

> Does this also happen with the qt6 VCL plugin or only with qt5/kf5?

Same with qt6.
Comment 14 Michael Weghorn 2024-02-01 08:19:41 UTC
(In reply to Michael Weghorn from comment #13)
> OK, I can somewhat reproduce something now:
> 
> 1) open attachment 192315 [details] with kf5/qt5/qt6 on Wayland
> 2) move through the document by dragging the handle in the vertical scrollbar

Note: This is with a dual-screen setup, both screens using 100% scaling and LO just being maximized on one of the screens, so nothing particularly special in the display settings.
Comment 15 Michael Weghorn 2024-02-01 08:24:15 UTC
(In reply to Michael Weghorn from comment #13)
> Maybe something is different in how Qt handles the mouse events on Wayland
> as compared to X11 (s. e.g. the QtWidget::mouseMoveEvent in the flamegraph),
> like maybe events are triggered more often now, so re-rendering the doc
> happens more often? (Just a wild guess.)

Note also the `QWindowSystemInterface::sendWindowSystemEvents` further down in the call stack, which is likely triggered by some event from the window system (Wayland/X11), which is where a Wayland vs. X11 difference might come from from further down the stack, which would then potentially be something outside of the direct control of LO and even Qt.