Bug 412761

Summary: Changing brush size with Shift + Drag becomes laggy when the brush size gets big.
Product: [Applications] krita Reporter: acc4commissions
Component: GeneralAssignee: Krita Bugs <krita-bugs-null>
Status: RESOLVED DUPLICATE    
Severity: minor CC: grzegorzpedrycz, manuel.snudl.zeidler, tamtamy.tymona
Priority: NOR    
Version: nightly build (please specify the git hash!)   
Target Milestone: ---   
Platform: Microsoft Windows   
OS: Microsoft Windows   
Latest Commit: Version Fixed In:

Description acc4commissions 2019-10-09 13:55:49 UTC 
SUMMARY
git 0cc05e0

It's not a new behavior, and it only happens when I do this using tablet pen (I'm using Wacom Intuos Pro medium).

It usually starts to happen as the brush size reaches around 350px. Brush type doesn't seem relevant.


SOFTWARE/OS VERSIONS
Windows: Win7
macOS: 
Linux/KDE Plasma: 
(available in About System)
KDE Plasma Version: 
KDE Frameworks Version: 
Qt Version: 

ADDITIONAL INFORMATION
Comment 1 Tiar 2019-10-09 13:57:35 UTC 
If it's only with the tablet, it might suggest a need for a signal compressor (tablet events are often more frequently sent) if updates take too much time. Didn't check it, so not confirming.
Comment 2 M 2019-10-10 00:28:19 UTC 

*** This bug has been marked as a duplicate of bug 402831 ***
Comment 3 Halla Rempt 2019-10-15 08:01:57 UTC 
*** Bug 412960 has been marked as a duplicate of this bug. ***
Comment 4 acc4commissions 2020-02-04 09:55:15 UTC 
It's gone in git 8e38e39! (It has been happened until, as far as I remember, git 7572e2d.)

There's still some framedrops when the brush size goes over around 600px, but it's not as laggy as it was before and fairly usable. I wouldn't know if you intentionally fixed it, but I think Imma be ok with this for now.
Comment 5 acc4commissions 2020-02-04 10:16:48 UTC 
I was wrong about one thing... What's strange is that it was not fixed in the build after Commit 0ca332c7089c690a62c6d7b66515fe9aacdabbdb(:Fix hiccups when doing canvas actions), but it was fixed in the next one I downloaded, which is git 8e38e39. 

Might be nothing. Just wanted to add.
Comment 6 Tiar 2020-02-04 10:28:26 UTC 
@acc the next commit (2fea6a9b28f5e9ec90cd06f5bbc79c7ef8e40ca2) was, if I remember correctly, also related, and it improves general performance quite a bit.
Comment 7 acc4commissions 2020-02-04 13:14:50 UTC 
(In reply to Tymond from comment #6)
> @acc the next commit (2fea6a9b28f5e9ec90cd06f5bbc79c7ef8e40ca2) was, if I
> remember correctly, also related, and it improves general performance quite
> a bit.

The build I downloaded which claimed that Commit 0ca332c7089c690a62c6d7b66515fe9aacdabbdb was applied to it also included the patch you mentioned. :q