| Summary: | Speed sensor breaks if the user attempts to draw during document creation | ||
|---|---|---|---|
| Product: | [Applications] krita | Reporter: | tomtomtomreportingin |
| Component: | Brush engines | Assignee: | Krita Bugs <krita-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | minor | CC: | dimula73, halla |
| Priority: | NOR | Keywords: | regression |
| Version: | nightly build (please specify the git hash!) | ||
| Target Milestone: | --- | ||
| Platform: | Appimage | ||
| OS: | Linux | ||
| Latest Commit: | https://invent.kde.org/graphics/krita/commit/060e7f8629181d565ffcc9721ab67f1a44af56b8 | Version Fixed In: | |
| Sentry Crash Report: | |||
|
Description
tomtomtomreportingin
2022-05-04 22:29:11 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. 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 |