After 10-15 cells are selected by STRG+Mouse Click there is a significant loss of speed in marking others. The more you choose the longer one have to wait until cells selection is shown.
Steps to reproduce: 1 Open a calc sheet 2 press and hold STRG and mark several cells or ranges (between 10-15) Actual Results: Calc needs more time to show cells selection the more you try to mark Expected Results: Stable performance while marking cells Reproducible: Always
Thank you for reporting the bug. I cannot reproduce the bug in Version: 6.0.6.2 Build ID: 0c292870b25a325b5ed35f6b45599d2ea4458e77 CPU threads: 2; OS: Windows 6.1; UI render: default; Locale: en-US (en_US); Calc: group
Made some additional tests related to this. After application restart the behavior occurs between 20-30 cells that are marked Second try with same sheet still open between 10-20 cells Seems that the more often you try the earlier the application slows down. CPU usage goes up to 100 percent while marking.
Another notice: Bug seems to be in connection with marking of several SINGLE cells only. Bug does not come up if one or more ranges are marked at first that contain a lot of cells before single cells are additionally(!) marked. Then a huge number of single cells can be marked without any system slow-down. Bug does come up if a lot of single cells are marked.
Created attachment 147633 [details] Video that shows described behavior and output of top command
confirm in Version: 6.2.0.1 Build ID: 0412ee99e862f384c1106d0841a950c4cfaa9df1 CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk3; Locale: ru-RU (ru_RU.UTF-8); UI-Language: en-US Calc: threaded
Reproduced in Version: 4.3.0.0.alpha1+ Build ID: c15927f20d4727c3b8de68497b6949e72f9e6e9e but not in Version 4.1.0.0.alpha0+ (Build ID: efca6f15609322f62a35619619a6d5fe5c9bd5a)
I can repro with master, but cannot repro with Linux bibisect repos 43, 44, 50max. Weird!!
Created attachment 148664 [details] Callgrind output from master Continued clicking until slowness was noticeable. Arch Linux 64-bit Version: 6.3.0.0.alpha0+ Build ID: bb30e9e591d5f9f913b3cd8fbaa3c5e412b509bd CPU threads: 8; OS: Linux 4.20; UI render: default; VCL: gtk3; Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US Calc: threaded Built on 23 January 2019
*** Bug 114767 has been marked as a duplicate of this bug. ***
I was able to reproduce this behaviour with version 6.2.0.3 on Ubuntu 16.04.6 LTS and ArchLinux. I also found out that this behaviour occurs with KDE in combination with the X11 composer. If you use KDE with the wayland composer, LibreOffice will run as usual.
I only repro this with gtk3 or gen, not with kf5. Maybe it is because of accessibility events. Arch Linux 64-bit Version: 7.1.0.0.alpha0+ Build ID: de1b634a151c198584dc152676183f519c50a2da CPU threads: 8; OS: Linux 5.6; UI render: default; VCL: gtk3 Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded Built on 12 June 2020
*** Bug 131486 has been marked as a duplicate of this bug. ***
*** Bug 130424 has been marked as a duplicate of this bug. ***
Still repro Version: 7.4.0.0.alpha0+ / LibreOffice Community Build ID: 32714f966186d301435d3eb9f7f6950bc9a6bb1e CPU threads: 8; OS: Linux 5.17; UI render: default; VCL: gtk3 Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded