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)
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.
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...
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.
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.
Also, I can't reproduce this on 5.0.6, so marking as a regression.
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.
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
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