Bug 453401 - Speed sensor breaks if the user attempts to draw during document creation
Summary: Speed sensor breaks if the user attempts to draw during document creation
Status: RESOLVED FIXED
Alias: None
Product: krita
Classification: Unclassified
Component: Brush engines (show other bugs)
Version: nightly build (please specify the git hash!)
Platform: Appimage Linux
: NOR minor
Target Milestone: ---
Assignee: Krita Bugs
URL:
Keywords: regression
Depends on:
Blocks:
 
Reported: 2022-05-04 22:29 UTC by tomtomtomreportingin
Modified: 2022-07-19 11:04 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description tomtomtomreportingin 2022-05-04 22:29:11 UTC
git ec92085

SUMMARY
The speed sensor becomes overly aggressive if the user attempts to make any strokes during the document creation process. This is with tablet driver timestamps disabled.

STEPS TO REPRODUCE
1. Observe how Ink-2 Fineliner behaves in normal circumstances.
2. Create a large document, then attempt to draw on the canvas during the initialization process.
3. Observe strokes from during document creation and after document creation.

OBSERVED RESULT
The speed sensor has become way too aggressive.

EXPECTED RESULT
The speed sensor should always remain consistent.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Debian sid
KDE Plasma Version: 5.24.4
KDE Frameworks Version: 5.90.0
Qt Version: 5.12.12 (appimage)
Comment 1 tomtomtomreportingin 2022-05-04 22:31:39 UTC
By the way, the breakage is localized to the specific document. Using a different document in the same session will not have the same breakage if the steps aren't reproduced for that particular document.
Comment 2 Halla Rempt 2022-05-10 12:50:52 UTC
To me, this kinda falls in the "don't do this" category. It would be nice to figure out why it happens, but it's not exactly high priority...
Comment 3 tomtomtomreportingin 2022-05-10 17:59:09 UTC
I would say it's more than minor since the reason for the breakage isn't obvious at all and it isn't too difficult to unintentionally reproduce. I encountered this at least two or three times without realizing why it was happening.
Comment 4 tomtomtomreportingin 2022-06-28 19:45:40 UTC
I'll say that I've encountered this issue at least a few more times since reporting this, without meaning to. If the speed is dependent on the canvas size, maybe there's some improper initialization due to the initialization of the canvas not being completed yet? 

novames00 on KA suggests that maybe the speed should be dependent on screen dimensions instead.
Comment 5 tomtomtomreportingin 2022-06-28 19:49:40 UTC
Also, I can't reproduce this on 5.0.6, so marking as a regression.
Comment 6 Dmitry Kazakov 2022-07-18 14:52:55 UTC
The problem is that the speed sensor breaks completely if the user clicks on the canvas while loading. The problem is not resolved until the document is reopened.
Comment 7 Dmitry Kazakov 2022-07-19 11:03:48 UTC
Git commit 21043b869592df7f27cd3770964dd771a4cf0ff2 by Dmitry Kazakov.
Committed on 19/07/2022 at 11:03.
Pushed by dkazakov into branch 'master'.

Fix a bug in brush speed calculation algorithm

KisSpeedSmoother used a rather naive implementation of the filtering
for the tablet event rate estimation. It just dropped the samples which
were too different from the current mean. It resulted in a weird bug:
when a lot of the tablet events were postponed by the blocked GUI-thread
(e.g. during image creation) the mean value fell into the cave of very
small values and couldn't be pulled out of it.

The patch implements a more clever approach using KisFilteredRollingMean
class. It keeps all the incoming values, but strips off the most extreme
values when calculating the mean.

The new algorithm is rather computation intensive, so we could think
about some lazy-computation solution for the future. But currently,
the whole computation takes about 7 microseconds, which is about 0.1%
of the GUI-thread's time for hight quality Wacom tablets.

M  +1    -0    libs/global/CMakeLists.txt
A  +90   -0    libs/global/KisFilteredRollingMean.cpp     [License: GPL(v2.0+)]
A  +75   -0    libs/global/KisFilteredRollingMean.h     [License: GPL(v2.0+)]
M  +15   -18   libs/ui/tool/kis_speed_smoother.cpp

https://invent.kde.org/graphics/krita/commit/21043b869592df7f27cd3770964dd771a4cf0ff2
Comment 8 Dmitry Kazakov 2022-07-19 11:04:04 UTC
Git commit 060e7f8629181d565ffcc9721ab67f1a44af56b8 by Dmitry Kazakov.
Committed on 19/07/2022 at 11:03.
Pushed by dkazakov into branch 'krita/5.1'.

Fix a bug in brush speed calculation algorithm

KisSpeedSmoother used a rather naive implementation of the filtering
for the tablet event rate estimation. It just dropped the samples which
were too different from the current mean. It resulted in a weird bug:
when a lot of the tablet events were postponed by the blocked GUI-thread
(e.g. during image creation) the mean value fell into the cave of very
small values and couldn't be pulled out of it.

The patch implements a more clever approach using KisFilteredRollingMean
class. It keeps all the incoming values, but strips off the most extreme
values when calculating the mean.

The new algorithm is rather computation intensive, so we could think
about some lazy-computation solution for the future. But currently,
the whole computation takes about 7 microseconds, which is about 0.1%
of the GUI-thread's time for hight quality Wacom tablets.

M  +1    -0    libs/global/CMakeLists.txt
A  +90   -0    libs/global/KisFilteredRollingMean.cpp     [License: GPL(v2.0+)]
A  +75   -0    libs/global/KisFilteredRollingMean.h     [License: GPL(v2.0+)]
M  +15   -18   libs/ui/tool/kis_speed_smoother.cpp

https://invent.kde.org/graphics/krita/commit/060e7f8629181d565ffcc9721ab67f1a44af56b8