SUMMARY 5.0 nightles, not a new behaviour. It becomes obvious as the brush size becomes bigger. I'd rather prefer brush being 'constantly' slow, rather than having it stutter at the every start of the stroke. It's more annoying in the current way. Renderer : Angle Texture buffer : on STEPS TO REPRODUCE 1. 2. 3. OBSERVED RESULT EXPECTED RESULT SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION
It is surely not a wishlist bug :)
Hi, acc4commissions! Could you state the sha1 of the nightlies you use? I have fixed exactly a bug like that in October.
(In reply to Dmitry Kazakov from comment #2) > Hi, acc4commissions! > > Could you state the sha1 of the nightlies you use? I have fixed exactly a > bug like that in October. It's present in the most recent nightlies. I used 1000px brush in e36a034 to test. Let me know if there's more info you need.
It seems that it doesn't happen that much when using Predefined brush tips. The stutter is the most obvious with Auto tips.
I found the biggest culprit. It was the Randomness option(the delay happens when it's set to other than 0) and the Density option(the delay happens when it's set to other than 100) that I was using. Although the delay still isn't completely gone even with optimal settings in both. There still seems to be many options contribute to the stutter at the start of the stroke(to be exact, an inherent short delay between you start a stroke and the actual stroke rendering starts). Using different Mask Type also makes differences.
Hi, acc4commissions! Thanks a lot for the info! Indeed, we have brush caching only for the predefined brushes. It was always believed that auto brushes are "fast enough" to skip caching :) I'll have a look into this bug later :)
Git commit d47a33aa9c7d1ba54cbe30f2d04263ca4aff7a92 by Dmitry Kazakov. Committed on 23/03/2022 at 12:29. Pushed by dkazakov into branch 'master'. Fix delay on auto-brush stroke with randomness KisAutoBrush used to initialize brushTipImage() and image() with a full-size preview image, which could cause huge delay for big brushes with randomness enabled. This patch disables initialization of brushTipImage() for auto-brushes (it is not used for them anyway). M +46 -11 libs/brush/kis_auto_brush.cpp M +1 -1 libs/brush/kis_auto_brush.h https://invent.kde.org/graphics/krita/commit/d47a33aa9c7d1ba54cbe30f2d04263ca4aff7a92
The delay has reduced! But still, compared to brushes that use Predefined tips, still there's a small gap, feels like a flicker before the actual brush rendering starts on canvas. I hope it's completely gone someday. But thanks for the patch overall.
(In reply to acc4commissions from comment #8) > The delay has reduced! But still, compared to brushes that use Predefined > tips, still there's a small gap, feels like a flicker before the actual > brush rendering starts on canvas. I hope it's completely gone someday. > > But thanks for the patch overall. nonono, sorry. I was testing the wrong nightly lol. The delay seems almost completely gone after the patch. Thank you! I'll post more if I find something else.
Git commit e62499df7d4fe14a26dde7edac8610bd1ad4bffb by Dmitry Kazakov. Committed on 31/03/2022 at 13:43. Pushed by dkazakov into branch 'krita/5.0'. Fix delay on auto-brush stroke with randomness KisAutoBrush used to initialize brushTipImage() and image() with a full-size preview image, which could cause huge delay for big brushes with randomness enabled. This patch disables initialization of brushTipImage() for auto-brushes (it is not used for them anyway). M +46 -11 libs/brush/kis_auto_brush.cpp M +1 -1 libs/brush/kis_auto_brush.h https://invent.kde.org/graphics/krita/commit/e62499df7d4fe14a26dde7edac8610bd1ad4bffb