Bug 140176 - UI: Speedup scrolling/paging by aborting redraw
Summary: UI: Speedup scrolling/paging by aborting redraw
Status: RESOLVED WONTFIX
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: needsDevEval
Depends on:
Blocks:
 
Reported: 2021-02-05 07:27 UTC by Robert Lacroix
Modified: 2021-02-07 18:09 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Lacroix 2021-02-05 07:27:53 UTC
Description:
Borrowing a technique employed by a 1980s vintage text editor in CP/M, scrolling can be made very fast by aborting a screen redraw when a new keystroke is detected in the same scrolling/paging direction.

Steps to Reproduce:
1. Load a large spreadsheet.
2. Fill up all your cores and 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 take 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 blazingly fast.

The spreadsheet currently buffers keystrokes and processes them serially with drawing, so you must wait for the drawing operation to complete for each keystroke. This is painfully slow in a large spreadsheet, on a slow CPU (or one that is fully in use). By looking ahead in the keystroke buffer while rendering the page, the program can decide to abort the current display update (which is going to be replaced anyway), then process the next keystroke and recommence the display update from the new position.


Reproducible: Always


User Profile Reset: No



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
Comment 1 Telesto 2021-02-06 07:16:01 UTC
@Luboš
Realistic or not?
Comment 2 Luboš Luňák 2021-02-07 18:09:10 UTC
I think this would be in so complicated that it in practice would be bordering on unrealistic. Drawing routines nowadays are way more complex than in the 1980s and trying to implement this would be asking for all kinds of problems (for example, scrolling does not do full redraws, but only newly needed areas are drawn, so "unneeded" repaints cannot be simply aborted).

Incidentally I have just pushed https://git.libreoffice.org/core/+/d3b498cc4732f964919fecb265085cefcc422469%5E%21 , which should significantly help with the problems described.

Unless you're willing to implement it yourself, I expect this would become a suggestion that nobody ever does.