Bug 154602 - Scrolling using keyboard very slow (GTK3) with 4K monitor
Summary: Scrolling using keyboard very slow (GTK3) with 4K monitor
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
7.3.1.3 release
Hardware: x86-64 (AMD64) Linux (All)
: medium major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, perf, regression
: 153007 155217 155375 157830 160647 (view as bug list)
Depends on:
Blocks: HiDPI GTK3 Scrolling-Performance
  Show dependency treegraph
 
Reported: 2023-04-04 12:36 UTC by Liudvikas
Modified: 2024-07-02 01:22 UTC (History)
11 users (show)

See Also:
Crash report or crash signature:


Attachments
Small CSV file that exhibits the bug on my computer (11.76 KB, text/csv)
2023-04-04 12:36 UTC, Liudvikas
Details
Sysprof 46 performance profiling capture (3.41 MB, application/x-xz)
2024-05-02 02:42 UTC, Jeff Fortin Tam
Details
Sysprof 46 capture screenshot - flamegraph (1.17 MB, image/png)
2024-05-02 02:43 UTC, Jeff Fortin Tam
Details
Sysprof 46 capture screenshot - graphics marks (376.27 KB, image/png)
2024-05-02 02:43 UTC, Jeff Fortin Tam
Details
Sysprof 46 capture screenshot - CPU usage (167.29 KB, image/png)
2024-05-02 02:43 UTC, Jeff Fortin Tam
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Liudvikas 2023-04-04 12:36:38 UTC
Created attachment 186471 [details]
Small CSV file that exhibits the bug on my computer

When holding down navigation keys to quickly scroll through the document, scroll is very laggy and even continues for a while after I've released the key. On 1920x1080, only left/right is laggy, but on 4K external monitor it's much worse overall and up/down is affected too. 

I'm attaching a sample document, it's barely 200x30 cells big. 

Fedora Linux 37
Lenovo ThinkPad P1 Gen 3
Intel® Core™ i9-10885H × 16
Mesa Intel® UHD Graphics (CML GT2)
Gnome 43.3
X11
Comment 1 Buovjaga 2023-04-11 11:23:40 UTC
I notice a slight difference when I use GTK3 and move with the arrows (pressing and holding) left and right through the cells with content. I don't have a 4K screen.

The difference is too subtle for me to effectively perform a bibisect, so I suggest that you try it with the 7.5 repository (it seems to not be in 7.4, but you can try it as well): https://wiki.documentfoundation.org/QA/Bibisect/Linux

The slowness might be related to accessibility as it works only with GTK3 for now. I see in the console sometimes:

** (soffice:73597): WARNING **: 14:20:09.963: atk-bridge: get_device_events_reply: unknown signature

Arch Linux 64-bit, X11
Version: 7.5.2.2 (X86_64) / LibreOffice Community
Build ID: 50(Build:2)
CPU threads: 8; OS: Linux 6.2; UI render: default; VCL: gtk3
Locale: fi-FI (fi_FI.UTF-8); UI: en-US
7.5.2-1
Calc: CL threaded
Comment 2 Liudvikas 2023-04-11 13:43:38 UTC
Installed 7.5.2.2 from an RPM on the official website, the bug persists :( exactly the same as reported AFAIK
Comment 3 Buovjaga 2023-04-11 13:45:43 UTC
If you need help in bibisecting, email me and I can guide you in a call.
Comment 4 Liudvikas 2023-04-11 13:47:01 UTC
Oh I see, you would like me to bibisect on my machine? I'll try and find the time then
Comment 5 Buovjaga 2023-05-16 16:25:07 UTC
*** Bug 155217 has been marked as a duplicate of this bug. ***
Comment 6 Telesto 2023-05-18 12:35:30 UTC
*** Bug 153007 has been marked as a duplicate of this bug. ***
Comment 7 Telesto 2023-05-18 12:36:28 UTC
*** Bug 155375 has been marked as a duplicate of this bug. ***
Comment 8 Telesto 2023-05-18 12:53:08 UTC
There are some bug reports about performance problems with Wayland. Others like bug 155375 comment 0 report no difference between x.org or Wayland. So might be caused by a 4k monitor or Wayland backend, or both.. Or maybe even something else
Comment 9 M. Knepper 2023-05-18 14:30:30 UTC
(In reply to Telesto from comment #8)
> There are some bug reports about performance problems with Wayland. Others
> like bug 155375 comment 0 report no difference between x.org or Wayland. So
> might be caused by a 4k monitor or Wayland backend, or both.. Or maybe even
> something else

I will test the 4k performance problem on Xorg sometime this week. I don't notice a difference between 1080p/1440p Wayland and Xorg - they're both very responsive. The problem seems to happen when the resolution is switched to something like 4k on Wayland.

We'll see if the problem persists on Xorg.
Comment 10 M. Knepper 2023-05-18 21:13:44 UTC
Played with LibreOffice (writer) at 4k on Xorg and i3wm. Same thing seems to happen. CPU usages spikes to 50% plus on a single thread/core for some reason.

Scrolling other applications like Firefox at 4k for example doesn't seem to push any particular CPU thread drastic usage levels.
Comment 11 Stéphane Guillou (stragu) 2023-10-24 18:49:07 UTC
Changing component to the whole of LibreOffice as two duplicates talk about Writer.
Comment 12 Timur 2023-11-21 12:57:40 UTC
Seems OK in 7.2. Repro with 4K in latest Linux bibisect 7.3 and 24.2. 
I used 100% scaling. Bug seen when scrolling over the bottom edge .
Bug 155217 seems a real dupe, others are for general slowness, to be checked.
Comment 13 Timur 2023-11-21 13:06:50 UTC
source 7c29b13ac67e3796b5998789371fa68acb01a260
author	Luboš Luňák <l.lunak@collabora.com>	Tue Jan 11 2022
committer	Caolán McNamara <caolanm@redhat.com>	Wed Jan 26 2022
avoid Xlib cairo surfaces for small virtual devices (bsc#1183308)

Luboš is not active anymore.
Comment 14 Stéphane Guillou (stragu) 2024-03-12 04:55:09 UTC
*** Bug 157830 has been marked as a duplicate of this bug. ***
Comment 15 M. Knepper 2024-04-03 01:09:15 UTC
I don't think this should be marked as trivial because, for most people, the slowness of 4k scrolling makes LibreOffice so horrible that it's better to use something else. 

A bug so bad that it makes you want to use a different program is not trivial. 

This isn't a severe security thing, but it's still important.

I wanted to add an update and say I'm still able to reproduce this bug. I haven't tried the latest packages on Arch, but it still exists on Debian, Ubuntu, and Fedora.
Comment 16 Jeff Fortin Tam 2024-05-02 02:42:31 UTC
Created attachment 193925 [details]
Sysprof 46 performance profiling capture

Let me put some objective measurements into the mix here with a profiling measurement using Sysprof. I reproduced this by using the provided CSV sample above and pressing-and-holding the down arrow button on the keyboard of a 4K HiDPI (@ 2x) Intel Kabylike laptop running Wayland GNOME on Fedora 39, with the Flatpak flathub version of LibreOffice:

Version: 24.2.2.2 (X86_64) / LibreOffice Community
Build ID: d56cc158d8a96260b836f100ef4b4ef25d6f1a01
CPU threads: 8; OS: Linux 6.8; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Flatpak
Calc: threaded

I will attach screenshots of the essentials of that sysprof capture.

My naïve observations:

* The overwhelming majority of time/efforts are spent in "PaintHelper" and "SdrPaintView" functions and the like, which ultimately spend a ton of time doing cairo_paint and cairo_fill everywhere.
* It seems to be single-threaded, as per the CPU usage graphs.

My gut feeling: it's probably spamming the backend as fast and often as keyboard input events are coming, without any throttling/smoothing. I don't think it makes sense for the app to be trying to respond to every event, 600 times per second (the 25-seconds sysprof recording shows 15 thousand function calls...).
Comment 17 Jeff Fortin Tam 2024-05-02 02:43:24 UTC
Created attachment 193926 [details]
Sysprof 46 capture screenshot - flamegraph
Comment 18 Jeff Fortin Tam 2024-05-02 02:43:38 UTC
Created attachment 193927 [details]
Sysprof 46 capture screenshot - graphics marks
Comment 19 Jeff Fortin Tam 2024-05-02 02:43:53 UTC
Created attachment 193928 [details]
Sysprof 46 capture screenshot - CPU usage
Comment 20 Caolán McNamara 2024-05-02 07:36:35 UTC
https://bugs.documentfoundation.org/show_bug.cgi?id=154602#c17 has a lot of "resizing" in the middle block which is odd, as presumably there isn't really any resizing expected, so possibly some glitch is triggering a continual cycle of resizing.

What might be worth exploring there is what theme is gtk3 using, default Adwaita or something else? I've seen cases on macOS where there was a constant tiny "jitter" triggering resizes, perhaps there is something similar here where changing the theme might perturb it.

The far left block looks directly associated with the cursor movement and subsequent draws though.
Comment 21 Jeff Fortin Tam 2024-05-02 19:59:01 UTC
> What might be worth exploring there is what theme is gtk3 using,
> default Adwaita or something else?

I don't know if this is what you're asking, but: my computers' GNOME sessions are running the standard Adwaita theme on Fedora (i.e. did not set anything else myself, and the distro does not ship its own theme either), and the version I tested here was the flatpaked version (so presumably unaffected by whatever is going on elsewhere); otherwise, I'm not entirely sure how to check what the app is "actually running"; it at least "looks" like GTK3 Adwaita, and the About dialog says it's GTK3, but as I don't seem to be able to just spawn the GTK Inspector from it (?) I have no way to be 110% sure.

Also: the sysprof capture seemed a bit incomplete because I was never able to figure out how to install the ".Debug" flatpak package for the freedesktop runtime, so I only had the "org.libreoffice.LibreOffice.Debug" extra flatpak package installed. If you have a magical trick to get the more complete symbols, I'm happy to try it.
Comment 22 Buovjaga 2024-05-27 15:10:23 UTC
*** Bug 160647 has been marked as a duplicate of this bug. ***
Comment 23 M. Knepper 2024-07-02 01:22:51 UTC
This a comment from a different duplicate bug thread catching the issue in action. It seems to get much worse at higher resolutions from my experience.

VIDEO LINK: https://www.youtube.com/watch?v=EXyMSzOVsds

Hardware:
13700k
7900xt
32gb DDR5
2tb SSD NVME

Software/OS:
Fedora 40
Linux 6.8x
LibreOffice 24.2.3.2
hTOP
Gnome 46
Gnome-Terminal
GPU drivers, VCL version, GTK version, etc, etc - whatever is on Fedora 40 as of this video.

Confirmed My Testing With:
2700x
RX 580 8gb
16gb DDR4
1tb SSD SATA
Linux 5.x
LibreOffice 7.6+

Note: This seems to happen regardless of using any widget toolkit such gtk, qt, whether it's on Xorg, Wayland, a Debian distro, an Arch distro, a Fedora based distro etc. I've been able to confirm for sure on different hardware and since version 7.6+ of LibreOffice. I plan to test newer versions soon.

As stated before, I tested it on 15k words to 50k words, 30 pages to 72 pages - it has high CPU usage either way. This doesn't happen on other word processors. 

The issue persists regardless of scaling. 100% scaling makes no difference and neither 200% scaling. 150% doesn't make a difference either.