Description: Suppose you have some document which is "heavy" to render (because of lots of complicated content, or because of inefficiencies/other bugs). Specifically, suppose that the time to render (and otherwise update the app state) takes more than the time difference between consecutive/repeated keystrokes. This means that if you press down some key - typically, an arrow key - one of two things can happen: 1. The app insists on rendering the result of each and every movement; the app will update/repaint/re-render based on keystrokes farther and farther away in the past. 2. The app notices it has a sequence of incoming keystrokes (or at least - a sequence of incoming identical keystrokes) beyond some length. At that point it collects the result of all of them (or all but the last few) and applies them altogether, rendering/updating state just once for all of them. This allows rendering/app state update to catch up with the physical typing. Currently, and mostly, it seems LO is choosing option (1.) rather than option (2.) If it were super-fast, then that would be an annoyance only in esoteric cases; but I get this occasionally - at least with Impress, with Draw and with Calc. Steps to Reproduce: 1. Open a slow-rendering document. 2. Move through a "difficult" area in that document using keyboard scrolling Actual Results: Rendering as though individual intermittent keystrokes were made; typing in "runs away" from rendering/updating Expected Results: App doesn't let typing "run away" like this. Reproducible: Always User Profile Reset: No OpenGL enabled: Yes Additional Info: As explained above - "catch up" to the typing by rendering the effect of multiple keystrokes together. A build within which I see this: Version: 7.0.3.1 Build ID: d7547858d014d4cf69878db179d326fc3483e082 CPU threads: 4; OS: Linux 5.2; UI render: default; VCL: gtk3 Locale: he-IL (en_IL); UI: en-US Calc: threaded GLX seems to be enabled. But I'll emphasize that this isn't about a particular recent version, I've noticed this repeatedly over the years.
Any change to add an example file. If need Sanitizing they file first https://wiki.documentfoundation.org/QA/Bugzilla/Sanitizing_Files_Before_Submission (however sounds pretty evil to achieve reading about they perf issues involved) They description isn't really surprising. Kind of interested in the root cause. Combination of tracking changes hidden and plenty of comments visible is one of they areas this happens. And also writing under an image in table under MacOS FWIW: Most of they time they root cause being investigates, and they slowdown seen as symptom. Instead of masking they issue by skipping paints etc
Created attachment 167379 [details] A spreadsheet exhibiting low-responsiveness Adding a document as request. Note: This bug is _not_ about LO Calc reacting slowly when working on the attached document. It is about _what_ the slow reaction should be when LO can't keep up with the keyboard input.