Description: Slow selecting a large multi-page table Steps to Reproduce: 1. Open the attached file 2. CTRL+A -> wait Actual Results: Performance isn't optimal Expected Results: Faster 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 159667 [details] Example file
Telesto please try test your problem with default UI render at once and compare it with Skia/Raster (Vulcan) UI render. Then we can to see it's a Skia problem or not.
3.3.0 is nearly instantaneous, but 3.5.0 is already slow. Also tested with Arch Linux 64-bit Version: 7.1.0.0.alpha0+ Build ID: ae3d26ba925f74c992a2d5cdfd44ed5d43968689 CPU threads: 8; OS: Linux 5.7; UI render: default; VCL: kf5 Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded Built on 20 June 2020
Telesto, you already reported Bug 106727 - EDITING: Select All is quite slow on a page containing a large table (72 rows and 20 columns). What's the difference to this issue?
*** This bug has been marked as a duplicate of bug 106727 ***