I have the a.m. version installed as well as an earlier version (6.1.5.2 because of Debian 10 has it and it cannot be removed). I found that the older version handles scrolling with keyboard (up and down arrows) better than the new version. What I do: Create a spreadsheet with 10000 rows and 1 column. I select A1, press and keep pressed the Down arrow. It starts scrolling. When I reach - about - row 200 I release the button. In the old version the scrolling stops immediately, as I expect it. In the new version the scrolling continues as long as the keyboard buffer has data in it. It stops around 300. Until I "just watch a movie" on the screen without being able to stop it (Esc or alike). The same with the PgDown, PgUp. If I push PgDown until I reach - about - row 5000, it continues to scroll to about row 8000. In a large spreadsheet it is rather hard to find a given location through scrolling, when it always overruns the target cell. So, unless it has a very strong reason, I would prefer the old behavior.
Some additional information would be helpful, there are similar reports * GTK3 backend? * 4k or not? * Wayland display server?
I hope you need these information: From the LO/Help/About Version: 7.5.3.2 (X86_64) / LibreOffice Community Build ID: 9f56dff12ba03b9acd7730a5a481eea045e468f3 CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3 Locale: en-GB (en_US.UTF-8); UI: en-US Calc: threaded From the terminal > loginctl show-session "$XDG_SESSION_ID" -p Type Type=x11 Display resolution 1920x1080x60.01Hz sometimes with an additional screen, but the issue exists even if only the main screen is used Shall I look for other data? P.S. Rather than for the display, to me it seems more a keyboard buffer issue. Even on the earlier release the scrolling speed was similar, so it is not necessarily that the scrolling is slow and hence cannot render as fast as the keyboard input is read. It is more, that the keyboard input is read and stored even if it cannot be processed immediately, but maybe I am wrong.
Confirmed using: Version: 7.5.2.2 (X86_64) Build ID: 50(Build:2) CPU threads: 1; OS: Linux 6.3; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded Version: 7.7.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 5a2c6f4df7149f8c1f543f120fe19bd66abfc189 CPU threads: 1; OS: Linux 6.3; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded Tried it with an older version and the scrolling stops as soon as the arrow button is released, i.e. the bug is not present in: Version: 7.4.7.2 / LibreOffice Community Build ID: 723314e595e8007d3cf785c16538505a1c878ca5 CPU threads: 1; OS: Linux 6.3; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded Also, it's not necessary to populate rows of the spreadsheet, the behavior appears even when the cells are empty, just hold down the down arrow for a few hundred rows and it keeps going.
*** Bug 155766 has been marked as a duplicate of this bug. ***
Setting to NEW, based on comment 3
*** Bug 155555 has been marked as a duplicate of this bug. ***
Created attachment 188390 [details] one column with 10000+ rows of the number 33
Bisected with linux-64-7.5, shows the following results commit cea5af03761842273c4e14b12d87f40aca7bb782 Author: Jenkins Build User <tdf@pollux.tdf> Date: Fri Aug 5 10:03:15 2022 +0200 source 7b20a1b0736825c9c934288428e6e581f79971e2 Which points to commit 7b20a1b0736825c9c934288428e6e581f79971e2 [log] author Caolán McNamara <caolanm@redhat.com> Thu Aug 04 16:32:10 2022 +0100 committer Caolán McNamara <caolanm@redhat.com> Fri Aug 05 09:52:50 2022 +0200 tree c9b534711745499fa31031f201cd8ee320b8cac4 parent 8c4e8818fe9f5ac1f6cdf908299cc109d67f1e50 [diff] Attached a spreadsheet to test with. For me, the bug shows after scrolling through about 300 rows when using gtk-3 Wayland. The bug is not present when using gtk-3 X-11. Changed first affected version to 7.5.0.0.alpha0+ Adding Cc: to <caolan.mcnamara@collabora.com>
Hi, I noticed the same problem and did a few basic tests in case that helps. I am running an older laptop DELL Inspiron 5558 with Ubuntu 20.04 (Gnome 3.36, kernel 5.15). I tested multiple versions of LO and concluded that, for me up to and including, version 7.0.6.2 the scrolling works well, but from version 7.1.0.1 the scrolling started to lag. However, testing other distributions in a Live environment, I had a very mixt result (I tested the LO versions that come out of the box with the live environment without setting up anything, or if LO was not included, then the only thing I did was to install it using the default package manager)(* - besides the live USB, also tested while properly installed): Ubuntu 24.04.1 (Gnome 46, kernel 6.8.0-41) LO version: 24.2.5.2 - LAG Kubuntu 24.04.1 (Plasma 5.27.11, kernel 6.8.0-41) LO version: 24.2.5.2 - OK LinuxMint 22 (Cinnamon, kernel 6.8.0) LO 24.2.4.2 - LAG Debian 12 (Gnome 43.9, kernel 6.1) LO 7.4.7.2 - OK Debian 12 (Plasma 5.27, kernel 6.1) LO 7.4.7.2 - OK Debian testing (Gnome 46, kernel 6.10.6) LO 24.2.5.2 - OK Debian testing (Plasma 5.27, kernel 6.10.6) LO 24.2.5.2 - OK Fedora 40 (Gnome 46, kernel 6.8.5) LO 24.2.2.1 - OK Manjaro 24.0.7 (Gnome 46, kernel 6.9.12) LO 24.2.5.2 - OK Manjaro 24.0.7 (Plasma 6, kernel 6.9.12) LO 24.2.5.2 - OK *Windows 10, LO version 7.6 - OK I recently had access to a newer laptop: XPS 9640 (maybe too new for proper Linux support), with different results: *Ubuntu 24.04.1 (Gnome 46, kernel 6.8.0-41) LO version: 24.2.5.2 - LAG Kubuntu 24.04.1 (Plasma 5.27.11, kernel 6.8.0-41) LO version: 24.2.5.2 - OK LinuxMint 22 (Cinnamon, kernel 6.8.0) LO 24.2.4.2 - LAG Debian 12 (Gnome 43.9, kernel 6.1) LO 7.4.7.2 - OK Debian 12 (Plasma 5.27, kernel 6.1) LO 7.4.7.2 - OK *Debian testing (Gnome 46, kernel 6.10.6) LO 24.2.5.2 - LAG *Debian testing (Plasma 5.27, kernel 6.10.6) LO 24.2.5.2 - OK Fedora 40 (Gnome 46, kernel 6.8.5) LO 24.2.2.1 - LAG Manjaro 24.0.7 (Gnome 46, kernel 6.9.12) LO 24.2.5.2 - LAG Manjaro 24.0.7 (Plasma 6, kernel 6.9.12) LO 24.2.5.2 - OK Windows 11 LO 24.8.0.3 - OK I know my tests are not very scientific, but as you can see, the appearance of this issue can be hit or miss depending on the hardware, kernel, desktop environment, and LO version (seems like the distro itself does not affect the issue). While my older laptop behaves nicely with newer OS versions, my new laptop does not really like to cooperate with Gnome. I just leave this comment here, not sure if it is helpful.
Might be that gtk_adjustment_set_value in the native gtk scrollbar is just slow/triggers a lot of extra work and maybe dispatching those to happen at idle or something of that nature might work better