Created attachment 185774 [details] Screencast 1. Open the attached ODS file 2. Place the cursor on the bottom row 3. Press PgUp and let the keyboard autorepeat kick in Expected: constant scrolling up Actual: jittery scroll, slower and slower, as seen in the screencast If the behavior isn't observed on the first, try, close the file, re-open it, and retry.
Created attachment 185775 [details] Horribly slow scrolling with Page Up
I've also noticed in this version than pasting a row from that file a few rows above or below it, is very slow (3-4 seconds). The row is around #10500, and this is another regression.
Issue still present in 7.5.2.2.
Super fast scrolling for me. Based on your screencast you are using KDE like me. Do always remember to paste the info from Help - About. If this is a regression for you, you can bibisect it https://wiki.documentfoundation.org/QA/Bibisect/Linux 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: kf5 (cairo+xcb) Locale: fi-FI (fi_FI.UTF-8); UI: en-US 7.5.2-1 Calc: CL threaded
Will try to bisect when I have some time, but for now I'm happy to report that on Fedora 37 KDE Wayland, scrolling is super fast in Calc 7.4.6.2 (albeit on a ThinkPad P1 Gen 5, rather than my old X1C Gen 7, but I strongly suspect the hardware is not the culprit). Version: 7.4.6.2 Build ID: 40(Build:2) CPU threads: 20; OS: Linux 6.2; UI render: default; VCL: kf5 (cairo+wayland) Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
Ok, if the issue is gone, we can close this.
Can't tell yet if the issue is gone, because on Fedora KDE I'm using 7.4, and in the OP, I had tested with 7.5 on Kubuntu with X11.
I can actually confirm. Tested on Ubuntu 20.04 with GNOME 3.36.8 + Wayland with: Version: 7.5.2.2 (X86_64) / LibreOffice Community Build ID: 53bb9681a964705cf672590721dbc85eb4d0c3a2 I made sure to zoom out a bit so columns A to K were visible. - With gtk3 VCL, no slowdown (although keeps scrolling for a bit after releasing the key) - With kf5 (cairo+xcb) VCL (window is GType:MetaWindowXwayland, so goes through Xwayland), same slowdown as in video, the interface sometimes unresponsive for a few seconds after stopping the scroll. The scroll takes the same time to get to the top, but it's the view that does not refresh frequently, hence the large jumps. - With kf5 (cairo+wayland) VCL (window GType:MetaWindowWayland, so Wayland native), no slowdown. If you use Wayland, you can see if using native Wayland works better by launching LibreOffice with extra variables from the command line, for example: SAL_USE_VCLPLUGIN=kf5 QT_QPA_PLATFORM=wayland libreoffice7.5
(In reply to Stéphane Guillou (stragu) from comment #8) > I can actually confirm. > > Tested on Ubuntu 20.04 with GNOME 3.36.8 + Wayland with: > > Version: 7.5.2.2 (X86_64) / LibreOffice Community > Build ID: 53bb9681a964705cf672590721dbc85eb4d0c3a2 What about 7.6? Regression testing?
(In reply to Buovjaga from comment #9) > What about 7.6? Regression testing? Same in: Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 1b06f35de68a555b85bceb5fc29d1a5f426f4bb7 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: kf5 (cairo+xcb) Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Bibisected with linux-64-7.1 repo to first bad commit d7ea8082722ab1c56993ef9d0c00d18230acaf45 which points to core commit: commit 65f42a4540d495a11d255af63c7ee15397b57bfa author Michael Meeks <michael.meeks@collabora.com> Thu Oct 22 19:45:16 2020 +0100 committer Noel Grandin <noel.grandin@collabora.co.uk> Wed Oct 28 13:08:15 2020 +0100 tdf#136694 - share spelling context across all ScGridWindows. Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104706 Before the commit, the view can choke up a little shortly after starting the scroll, but goes back to frequently refreshing. After the commit, same as in the video: very infrequent refreshing, all the way to the top. Looking at the commit, I figured turning off Tools > Automatic Spell Checking fixes the issue. Michael, can you please have a look? Dan, can you confirm that: - it only happens with kf5 (cairo+xcb) - turning Automatic Spell Checking makes it smoother
Fun - so, there's nothing obvious from the patch there - it should save time and space. What would be useful would be running perf on it to see where the bottleneck is I think; and/or running a dbgutil build with: SAL_LOG="+INFO.vcl.schedule" And then seeing what it produces while you scroll; I expect that we're doing too much spell-checking work vs. rendering work for some reason - that is (no doubt) related to some quirk of how the events are processed.
Adjusting summary as Dan originally found this under X11
I've done more testing. With 7.5.2.2 on KDE Wayland, I see fast scrolling, getting slightly slower after scrolling up a few thousand rows, but nothing to complain about. Scrolling again from the last row towards the top while keeping the document open is noticeably faster (perhaps some caching happens?) Version: 7.5.2.2 (X86_64) / LibreOffice Community Build ID: 53bb9681a964705cf672590721dbc85eb4d0c3a2 CPU threads: 20; OS: Linux 6.2; UI render: default; VCL: kf5 (cairo+wayland) Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded On MacOS though, scrolling the same file is much slower, and uniformly so (doesn't get slower as I scroll up). I tried both 7.4, and the latest: Version: 7.5.2.2 (X86_64) / LibreOffice Community Build ID: 53bb9681a964705cf672590721dbc85eb4d0c3a2 CPU threads: 10; OS: Mac OS X 13.2.1; UI render: default; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded