https://bugs.documentfoundation.org/show_bug.cgi?id=140405
--- Comment #4 from Robert Lacroix <[email protected]> --- (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. -- You are receiving this mail because: You are the assignee for the bug.
