https://bugs.kde.org/show_bug.cgi?id=510627
Bug ID: 510627
Summary: "layer-thumbnails-stroke" KisIdleTaskStrokeStrategy
blocks UI and freezes input
Classification: Applications
Product: krita
Version First git master (please specify the git hash!)
Reported In:
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: * Unknown
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
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
--
You are receiving this mail because:
You are watching all bug changes.
