Particularly with long text documents containing images, scrolling performance is much slower when using the keyboard's directional arrow keys (not PageUp/PageDown) than when using the mouse wheel. One side-effect is that if you press and hold for more than a few seconds, when you release the key LibreOffice Writer will keep scrolling for a while until it stopped processing the queue of keypress events. I posit that the reason why the mousewheel is more performant is that its scroll events are discrete (I don't have one of those analog super-smooth scroll wheels or touchpads, mine just goes "click click click" while you rotate the wheel), whereas pressing and holding the keyboard's arrow keys generates dozens of events per second, flooding LibreOffice with those. The result is that scrolling "feels" slower than it could be if those events were "compressed" to a lower rate. Of course, in an ideal world any kind of scrolling (including "smooth" scrolling) should be performant and responsive. I'm just saying that I see better scrolling performance with "clicky" mousewheels than the keyboard, and that there could be a possibility of optimizing the keyboard (i.e.: "don't do too much/needless work") to match that kind of performance.
Sounds a bit similar to bug 112568, bug 94109 or bug 104716
Which LibreOffice version are you using ? Please could you check if your problem is the same as bug 112568 ? If not, please provide a test file with which you encounter the problem you describe. Set status to NEEDINFO, please set it back to UNCONFIRMED once requested informations are provided. Best regards. JBF
Created attachment 140573 [details] sample file Hi, this is with LibreOffice 5.4.5 on Fedora 27 64-bit, though I've experienced this issue with every version of LibreOffice (and previously OpenOffice) throughout the years. Attaching a simplified test sample file. Not the same as bug #112568 as I have no responsiveness issue when typing text in my documents, just that keyboard scrolling is very slow (as described above, with the events "queue" being presumably flooded) compared to mousewheel scrolling. Grab my sample document, press and hold the "down" arrow and you should be able to experience it too.
No problem here with scroll queue or slowness of any kind. Tried also with gtk3. Arch Linux 64-bit Version: 6.0.2.1.0+ Build ID: 6.0.2-1 CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: kde4; Locale: fi-FI (fi_FI.UTF-8); Calc: group
A few observations (with LibO on Windows) * The scrolling experience scrolling with the arrow keys is very smooth in read only mode (CPU usage is a bit extreme for my taste) compared to edit mode (so inconsistent) * The arrow scrolling speed is also a little inconsistent.. The text scrolls a little faster compared to image (I tested it with a zoom factor 140; only image visible in read only mode) * The caret might (1:8) move a few lines after release of the arrow key (only 2 or 3) after scrolling 2/3 pages * The page counter isn't working when holding the arrow key (or using page down/page up key) Version: 6.1.0.0.alpha0+ Build ID: e5bc7fa4e83b33fc3eee343e560a4f8cb91eacd6 CPU threads: 4; OS: Windows 6.3; UI render: default; TinderBox: Win-x86@42, Branch:master, Time: 2018-03-14_23:37:38 Locale: nl-NL (nl_NL); Calc: CL
hi, Issue occurs in version 6.0.2 windows 7 (32bit). Change the status as NEW.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
This should probably be gone by now
Smooth, no issue on Windows Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community Build ID: dc3b64dcbfb0a49c0be65bd8d73ed4e6d3828a21 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: nl-NL Calc: CL @Ilmari Any change to test this against GTK3/KDE to be sure; Skia is likely the best performing backend at this point in time