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>