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
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
Installed 7.5.2.2 from an RPM on the official website, the bug persists :( exactly the same as reported AFAIK
If you need help in bibisecting, email me and I can guide you in a call.
Oh I see, you would like me to bibisect on my machine? I'll try and find the time then
*** Bug 155217 has been marked as a duplicate of this bug. ***
*** Bug 153007 has been marked as a duplicate of this bug. ***
*** Bug 155375 has been marked as a duplicate of this bug. ***
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
(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.
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.
Changing component to the whole of LibreOffice as two duplicates talk about Writer.
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.
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.
*** Bug 157830 has been marked as a duplicate of this bug. ***
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.
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...).
Created attachment 193926 [details] Sysprof 46 capture screenshot - flamegraph
Created attachment 193927 [details] Sysprof 46 capture screenshot - graphics marks
Created attachment 193928 [details] Sysprof 46 capture screenshot - CPU usage
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.
> 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.