https://bugs.documentfoundation.org/show_bug.cgi?id=147794
--- Comment #7 from Dmitry INEC <[email protected]> --- i can kind of confirm... i was confused by the button just ignoring all users actions ( #147868 ) then i finally successfully googled for it and found the reason. The workbook itself is small, but has some nested area-summing formulas and conditional formatting. Also my Win7x64 office computer works noticeably slow this morning, dunno why, maybe admins run HDD backup or something. So, i undone "sheet structure protection" and then probably clicked that [+] button yet seen no action, and perhaps clicked it again, or right clicked, not sure? I also believe (but my memory may be not exact) i then right-clicked on the sheet tabs, i think, to check if context menu now has more items. Well, one way or another in the end i clicked [+] button and saw TWO sheets created. I could not reproduce it - the "execution path" was warmed up and the reaction to that button was instant. However i speculate that if you would reproduce "slow win64 computer" - for example severly downclocking CPU and prohibiting L1/L2 caches in BIOS and do a reboot, then early after login, while Windows Defender antivirus and Windows AutoUpdate would make your HDD (not SSD) busy - you probably would be able to reproduce the GUI slugishness. I speculate when the button is clicked some event is asynchronously enqueued. In Windows that would be PostMessage API, but since OOo/LO use some x-platform toolkit it may be something else. In the end as user keeps clicking getting no reaction from the program - the queue gets many async actions in it. When the code path is finally warmed up - they are rushed to execution all at once. I don't when exactly this happens. Easy fix would be to record "current number of sheets" as a property of the action command to enqueue. Then all "actions" that do not have current counter equal to the recorded one would be ignored. Lazy synchronization. However this presumes GUI itself works almost instantly and the slugishness kicks in later. If those are OS-level events (like WM_MOUSEDOWN GetMessage in Windows case) that are amassed and processed with huge delay as huge batch - then bad luck, this counter marking would not fix it. -- You are receiving this mail because: You are the assignee for the bug.
