Bug 510627

Summary: "layer-thumbnails-stroke" KisIdleTaskStrokeStrategy blocks UI and freezes input
Product: [Applications] krita Reporter: Ming Chuan <ming>
Component: * UnknownAssignee: Krita Bugs <krita-bugs-null>
Status: REPORTED ---    
Severity: normal CC: halla
Priority: NOR    
Version First Reported In: git master (please specify the git hash!)   
Target Milestone: ---   
Platform: Other   
OS: Linux   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:

Description Ming Chuan 2025-10-15 05:24:55 UTC
SUMMARY

```
WARNING: idle task consumed more than 200ms, it can cause visible distractions to the user
WARNING: time consumed in "layer-thumbnails-stroke" is 1000ms
```

https://invent.kde.org/graphics/krita/-/blob/87ec67592d6fc7ed15a1b19d40e3a520738d29e9/libs/ui/KisIdleTaskStrokeStrategy.cpp#L51-65 is consistently triggered by "layer-thumbnails-stroke" action, when user have any non-trivial layer setup such as filter layers with many layers.

Krita becomes unresponsive and blocks user input, resulting in a poor user experience. A typical scenario looks like this

When the thumbnail computation is running, krita become unresponsive and blocks user input, causing bad user experience. Typical scenario:

1. User make a stroke
2. User thinks briefly to decide if the stroke is good or not, for 200ms (`4 * preferredIdleWatcherInterval()`).
3. "layer-thumbnails-stroke" KisIdleTaskStrokeStrategy starts running, blocks user input, sometimes more than 1000ms.
4. User presses undo while the thumbnail update is still running, and krita just ignores it. (Not even undoing after it unblocks)

I don't know if there is a valid reason for this thumbnail update to block user input or the event loop. Since it’s a low-priority background task, it should be possible to offload the computation.

A cheap workaround is to turn up `preferredIdleWatcherInterval()` to lower the chance of user hitting this.

STEPS TO REPRODUCE
1. Run something like https://gist.github.com/sifmelcara/987e0c3a2eee82ad5bd58dc3e4ec00f4 to get a non-trivial layer setup
2. Paint on the inner most paint layer while the layers docker is visible, observe the extreme lag
3. Paint in fullscreen mode, observe that the lag caused by thumbnail update is gone

You can also try change `preferredIdleTaskMaximumTime()` to lower the threshold of warning, to make the issue more visible in log.

SOFTWARE/OS VERSIONS

Note that this is a regression introduced to master branch, not in 5.2.13 release

ADDITIONAL INFORMATION
Comment 1 Halla Rempt 2025-10-15 07:24:59 UTC
Extra note:

07:41:16 < sifmelcara[M]> Hmm just found
                          https://invent.kde.org/graphics/krita/-/commit/572c64858d1b506ca1500b776cc49dfd65105ddd
                          and realize that the delay was actually reduced in order to speed up overview docker
                          update. The time-consuming layer thumbnails update scenario wasn't considered