Description: Slow Table lay-outing Steps to Reproduce: 1. Open the attached file (somewhere from the bug tracker) 2. Enter cell Szene 3. Hold enter for 4 seconds... Actual Results: Layout 'loop' (not sure if recursive) starts. Expected Results: It should finish within reasonable time frame Reproducible: Always User Profile Reset: No Additional Info: Version: 7.0.0.0.alpha0+ (x64) Build ID: 4475bcd83aac7e033fc5250f268eb922bd471e7b CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win; Locale: nl-NL (nl_NL); UI-Language: en-US Calc: CL
Created attachment 159664 [details] Example file
It's also possible to crash the document. Pressing Enter a view times + UNDO. However, the 90% change hitting a layout loop first
Created attachment 164931 [details] Perf flamegraph Repro Arch Linux 64-bit Version: 7.1.0.0.alpha0+ Build ID: d784e711c102f204552c3c816636da01b1085f61 CPU threads: 8; OS: Linux 5.8; UI render: default; VCL: kf5 Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded Built on 29 August 2020
Loop doesn't seem to be hit consistently. Tried with some bibisect repos, but not confident to attempt bibisect.
Lets assume bug 121720 being the root cause *** This bug has been marked as a duplicate of bug 121720 ***