Description: The spreadsheet buffers keystrokes and processes them in sequence with each drawing operation. If the user causes the screen to scroll multiple times in rapid succession, the entire page is redrawn with each keystroke. This can take a long time when the CPU or GPU are busy or underpowered. This proposal removes redundant screen drawing by using a greedy algorithm to consume the sequence of multiple keystrokes (if any) in the keyboard buffer to reposition the active cell before causing the screen to redraw (stopping the lookahead at any keystroke which doesn't scroll the screen, if any). In this scenario, we do NOT add delays between reading the keyboard and drawing the screen (to give the user an opportunity to hit more keystrokes) as this would make the program stutter for people with fast screen updates. If the screen can be redrawn faster than the user can press keys, then the software behaves the same. But if redrawing takes longer, then the user may have placed multiple keystrokes in the buffer before LO Calc checks the keyboard again - this is when the enhancement would help the user. This enhancement has no change to the screen rendering part of the software, hence it is simpler and more realistic than the proposal in https://bugs.documentfoundation.org/show_bug.cgi?id=140176 which requested that drawing be aborted. Only the the event loop and dispatch are affected in this enhancement request. The event loop would consume a keystroke, determine if the screen would scroll, and if so update the active cell position and continuing reading the keyboard, until either there are no keystrokes left in the buffer, or the keystroke would not cause the screen to scroll (so put it back in the buffer). Then proceed with updating the screen. Steps to Reproduce: 1. Load a large spreadsheet. 2. Fill up all your cores and (especially) your GPU with heavy processing. A distributed computing project is a good candidate. 3. Go to the top of the spreadsheet. 4. Hit the page-down key several times quickly. Actual Results: Watch how long LO Calc takes to reach the desired cell, and how frustrating it is to recover from hitting page-down too many times after passing that cell. Expected Results: It could be faster. Reproducible: Always User Profile Reset: No Additional Info: Additional Info: Version: 7.0.4.2 Build ID: dcf040e67528d9187c66b2379df5ea4407429775 CPU threads: 12; OS: Linux 4.19; UI render: default; VCL: gtk3 Locale: en-CA (en_CA.utf8); UI: en-US Calc: threaded
+1, reasonable but why just for spreadsheets, and why only cursor up/down scroll moves why not for <pgUp>/<pgDwn> or the scrollbar 'thumb' widget moves? Calculate where the canvas will end up after the buffered movements and only draw that. Kind of the antithesis to 'smooth scroll'
Version: 7.0.4.2? This is most likely outdated.
Rather than proposing a solution it's better to report an issue (and suggest a solution). Searching for "slow scrolling" in Calc returns bug 119362: Very slow horizontal scrolling when wrapping is enabled bug 123419: Scrolling around in a document with lots of comment shown very slow compared to 4.4.7.2 bug 124963: Slow scrolling of large xls file with many images bug 120446: Slow scrolling a ODS with some text bug 113495: Calc: very slow scrolling - nearly impossible to work with a graphic inside bug 139718: Scrolling a sheet with marked column or row results in the colored / highlighted cells being drawn too slow I suggest you pick one appropriate and comment there.
(In reply to V Stuart Foote from comment #1) > +1, reasonable but why just for spreadsheets, and why only cursor up/down > scroll moves why not for <pgUp>/<pgDwn> or the scrollbar 'thumb' widget > moves? Calculate where the canvas will end up after the buffered movements > and only draw that. Kind of the antithesis to 'smooth scroll' Correct, jump scrolling. I mentioned <Page Down> in the example to reproduce, and the description talks about any keystroke that causes the screen (I meant window) to be redrawn. This could be a horizontal repositioning or scrollbar activity. The fundamental observation is that doing this while the video card is extremely busy with a background computation makes Calc difficult to use. It doesn't really matter what you are trying to render in the Calc window, the problem is that Calc does so much redundant rendering that I could walk away from the computer and come back in a minute and it would still be processing the scrolling operations for a dozen <Page Down> keystrokes. I did say a "large spreadsheet", to have sufficient content to demonstrate the effect of buffered keystrokes while scrolling, and a *very busy GPU*. In my case the offending worksheet has over 6500 rows and 37 columns. Sure, it's my fault for loading the GPU 99% with computations, but the reason could equally well have been because of playing a video in another window while using Calc, on a computer with a wimpy GPU. Some applications deal with this better than others. Calc is the worst offender because of the redundant drawing that is immediately over-written when scrolling is happening.
(In reply to Heiko Tietze from comment #3) > Rather than proposing a solution it's better to report an issue (and suggest > a solution). Searching for "slow scrolling" in Calc returns > > bug 119362: Very slow horizontal scrolling when wrapping is enabled > bug 123419: Scrolling around in a document with lots of comment shown very > slow compared to 4.4.7.2 > bug 124963: Slow scrolling of large xls file with many images > bug 120446: Slow scrolling a ODS with some text > bug 113495: Calc: very slow scrolling - nearly impossible to work with a > graphic inside > bug 139718: Scrolling a sheet with marked column or row results in the > colored / highlighted cells being drawn too slow > > I suggest you pick one appropriate and comment there. I took your suggestion seriously and looked at the proffered issues as you have obliged me. I respectfully decline because this solution affects them all. Specifically, it's not any particular feature of Calc that is causing slow scrolling, it's the way Calc draws windows redundantly when scrolling which is at the root of most, if not all, of these issues. I therefore request that you make all of the scrolling issues dependent upon this one, and then see how many of them are still standing after this solution has been attempted.
[Automated Action] NeedInfo-To-Unconfirmed
The dev advice is in comment #2: This is most likely outdated and not a problem with any supported LO version (or maybe 7.3+, not sure). Can somebody test that?
OK, purely an enhancement then and not a performance issue--which I agree with Luboš has been addressed with the Skia framework. Rather eliminate any semblance of frame scrolling and buffer the movements to "jump" to the final positioning of the canvas with just one frame draw. As I said, the 'antithesis' to folks desiring "smooth scrolling". @Luboš, in that context would this be a feasible enhancement? For optional use of course...
(In reply to V Stuart Foote from comment #8) > @Luboš, in that context would this be a feasible enhancement? For optional > use of course... In the context in which somebody verifies that this is still actually a problem. See comment #7 again, this has been reported for LO version that was branched off ~20 months ago and might have been improved meanwhile. And even if this is still valid, the most of the bugreport is actually not that useful. The problem appears to be somewhat artificial (of course LO is going to be slow on an overloaded system), the bugreport is just a theoretical proposal without any code coming with it, and even the suggestion is questionable (if still still needs fixing, there should be better ways to handle this than something as fragile/complex as input look-ahead). So IMO if the problem description is deemed good enough, then this is only usable as a request for a would-be-nice enhancement.
(In reply to Luboš Luňák from comment #9) > this is only usable as a request for a would-be-nice enhancement. Well sure, and it is annotated as such in the Importance fields. But OP still ought to provide you the requested retest with a current build--preferably of a parallel install the master branch or even with 7.3.2 [1] where there certainly has been a lot of effort in improving display refresh. =-ref-= [1] https://wiki.documentfoundation.org/Installing_in_parallel
(In reply to V Stuart Foote from comment #10) > (In reply to Luboš Luňák from comment #9) > > > this is only usable as a request for a would-be-nice enhancement. > > Well sure, and it is annotated as such in the Importance fields. > > But OP still ought to provide you the requested retest with a current > build--preferably of a parallel install the master branch or even with 7.3.2 > [1] where there certainly has been a lot of effort in improving display > refresh. > > =-ref-= > [1] https://wiki.documentfoundation.org/Installing_in_parallel Tested just now with Version: 7.4.0.0.alpha0+ / LibreOffice Community Build ID: 55b20c8781d7718fa992769df90282563694f7fe CPU threads: 12; OS: Linux 5.10; UI render: default; VCL: gtk3 Locale: en-CA (en_CA.utf8); UI: en-US Calc: CL The slow behaviour is definitely still there. I pressed the Page Down key 20 times and it took 15.48 seconds to end up at the destination cell.
(In reply to Robert Lacroix from comment #11) > (In reply to V Stuart Foote from comment #10) > > (In reply to Luboš Luňák from comment #9) > > > > > this is only usable as a request for a would-be-nice enhancement. > > > > Well sure, and it is annotated as such in the Importance fields. > > > > But OP still ought to provide you the requested retest with a current > > build--preferably of a parallel install the master branch or even with 7.3.2 > > [1] where there certainly has been a lot of effort in improving display > > refresh. > > > > =-ref-= > > [1] https://wiki.documentfoundation.org/Installing_in_parallel > > Tested just now with > Version: 7.4.0.0.alpha0+ / LibreOffice Community > Build ID: 55b20c8781d7718fa992769df90282563694f7fe > CPU threads: 12; OS: Linux 5.10; UI render: default; VCL: gtk3 > Locale: en-CA (en_CA.utf8); UI: en-US > Calc: CL > > The slow behaviour is definitely still there. > I pressed the Page Down key 20 times and it took 15.48 seconds to end up at > the destination cell. That was with the GPU loaded at 100%. With the GPU loaded at 0% the destination cell was reached essentially in the time it took me to strike the key 20 times.