Bug 412761 - Changing brush size with Shift + Drag becomes laggy when the brush size gets big.
Summary: Changing brush size with Shift + Drag becomes laggy when the brush size gets ...
Status: RESOLVED DUPLICATE of bug 402831
Alias: None
Product: krita
Classification: Applications
Component: General (show other bugs)
Version: nightly build (please specify the git hash!)
Platform: Microsoft Windows Microsoft Windows
: NOR minor
Target Milestone: ---
Assignee: Krita Bugs
URL:
Keywords:
: 412960 (view as bug list)
Depends on:
Blocks:
 
Reported: 2019-10-09 13:55 UTC by acc4commissions
Modified: 2020-02-04 13:14 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:

Attachments
Add an attachment

Note You need to log in before you can comment on or make changes to this bug.
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