Reproduction instructions: 1. Create a new Writer doc 2. (Make sure the the style 'Heading 1' has a 'Next Paragraph Style' set to something else, e.g. 'Body Text') 3. Type some text, e.g. "A heading" 4. Set the paragraph style to 'Heading 1' 5. Type a sequence of keyboard keys, with as little delay between typing, beginning with Enter. It may be useful to use both hands, so that one hand types the Enter and the second just taps away on various characters without worrying about what it is that you're typing (in case you're not a very quick typist). Ideal expected result: When the cursor moves to the beginning of the new paragraph, the style name (on the Toolbar and Sidebar) changes (e.g. to 'Body Text'). Tolerable expected result: A short time after the cursor moves to the beginning of the new paragraph, the style name (on the Toolbar and Sidebar) changes (e.g. to 'Body Text'). Actual result: Only after you stop typing - even if it's for a period of 5, 10, or whatever number of seconds, does the style name change from 'Heading 1'.
Hello Eyal Rozenberg, Thank you for reporting the delay issue. I can confirm that this behavior is present in both the Alpha and Live versions. Version: 25.8.3.2 (X86_64) Build ID: 8ca8d55c161d602844f5428fa4b58097424e324e CPU threads: 8; OS: Windows 10 X86_64 (build 19045); UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded Version: 26.2.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 620(Build:0) CPU threads: 8; OS: Windows 10 X86_64 (build 19045); UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded
Already in oldest of linux-43all repo.
Adding perf keyword per discussion in dev chat (we don't need such aggressive debouncing tactics anymore).
(In reply to Buovjaga from comment #3) > Adding perf keyword per discussion in dev chat (we don't need such > aggressive debouncing tactics anymore). So, there are actually several questions to ask here: 1. Should we have "debouncing" / delayed reaction at all? 2. If we have debouncing, how long should it be for? 3. Should "debouncing" be continously re-triggerable by actions such as typing (and thus, potentially, infinite)? I'm sure the answer to (3.) is negative. Once we've started counting some delay, we should not reset that counter; the UI should be recomputed/repainted/updated after that timeline expires, even if an additional debounce-triggering event occures. About questions (1.) and (2.) I am not too sure. But - I would think that this should depend on how fast the machine we're running on actually is, and perhaps what load level it's under. If that's at all possible to check. I leave that part to the capable hands of the developers. > When some area gets heavy interaction, it does not make sense > to spend CPU time in real-time monitoring. But maybe the behaviour can be > tweaked without harming performance. There is also the question of what constitutes "heavy interaction". Is typing text after having typed Enter, in an otherwise empty document, heavy interaction?