Bug 415773 - Krita 4.2.8 freezes when SHIFT-resizing brush
Summary: Krita 4.2.8 freezes when SHIFT-resizing brush
Status: RESOLVED FIXED
Alias: None
Product: krita
Classification: Applications
Component: General (show other bugs)
Version: 4.2.8
Platform: Appimage Linux
: NOR major
Target Milestone: ---
Assignee: Dmitry Kazakov
URL:
Keywords: regression, release_blocker
Depends on:
Blocks:
 
Reported: 2020-01-01 18:22 UTC by Kruthers
Modified: 2020-02-03 21:47 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kruthers 2020-01-01 18:22:22 UTC
Using SHIFT + left mouse button click & drag to resize the brush causes krita to freeze for long periods of time.  This only happens in 4.2.8; the problem is not there in 4.2.7-beta1.  Identical behavor happens when using a tablet instead of the mouse.

See this video for a demonstration:    https://vimeo.com/382303909


STEPS TO REPRODUCE
1. Use a brush like airbrush_soft with a simple circular outline
2. shift-click-drag on the canvas for a few seconds to try to resize brush
3. wait for up to a minute for krita to become responsive again

OBSERVED RESULT
Krita freezes but not permanently; it will eventually wake up.

EXPECTED RESULT
Same as 4.2.7, or even more responsive would be nice. ;)

SOFTWARE/OS VERSIONS
Linux/KDE Plasma:       Kubuntu 18.04
KDE Plasma Version:     5.12.9
KDE Frameworks Version: 5.44.0
Qt Version:             5.9.5


ADDITIONAL INFORMATION

> uname -a
Linux mephistopheles 4.15.0-72-generic #81-Ubuntu SMP Tue Nov 26 12:20:02 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

CPU: AMD Athlon II X4 640 (4 cores)

Nvidia driver version: 390.129

In Krita settings, Canvas Graphics Acceleration is ON

Both 4.2.7-beta1 and 4.2.8 are the appimage releases.
Comment 1 Halla Rempt 2020-01-03 13:52:21 UTC
I'm sorry, but I cannot reproduce this with the 4.2.8 appimage with either my tablet or my mouse. Is your mouse by any chance a hires gaming mouse? Can you also check the latest nightly build? See https://binary-factory.kde.org/job/Krita_Nightly_Appimage_Build/
Comment 2 Kruthers 2020-01-03 19:31:05 UTC
(In reply to Boudewijn Rempt from comment #1)
> I'm sorry, but I cannot reproduce this with the 4.2.8 appimage with either
> my tablet or my mouse. Is your mouse by any chance a hires gaming mouse? Can
> you also check the latest nightly build? See
> https://binary-factory.kde.org/job/Krita_Nightly_Appimage_Build/

Sure, I just tried krita-4.3.0-prealpha-9526f28-x86_64.appimage and it freezes the same as 4.2.8 for me.

Yes it is a gaming mouse.  But the tablet (Wacom Intuos) has the same problem so that shouldn't be the cause I assume.  Just to be safe though I unplugged it and used a regular Logitech mouse but it made no difference.

I tried both versions of Krita on a laptop and 4.2.8 was slower than 4.2.7, but not nearly as bad as this report, ie. not to the point of freezing up for long periods of time.  This is strange because the laptop is underpowered compared to the desktop machine.

However, I was able to partially recreate the problem on the laptop by increasing the maximum brush size to 2000px.  Then when I scrubbed the scale values back and forth in the larger sizes (say between 1500 and 2000px), 4.2.8 was freezing for a few seconds at a time, whereas 4.2.7 was merely sluggish.

Not sure why my desktop severely chokes on this, but you should be able to experience the performance decrease with the above procedure...

A few others things I tried:
- completely fresh preferences (under a different account so I wouldn't miss something)
- disabling canvas acceleration
Neither made a difference.

Does the fact that it happens with canvas acceleration disabled rule out graphics drivers being the cause?

The only other thing I can think of is that my desktop is an AMD cpu and the laptop is Intel.  Could the brush resize code be using intel-specific instructions?

In any case, thanks for looking into this.  I will be happy to do any other tests you can think of.
Comment 3 Bug Janitor Service 2020-01-04 04:33:09 UTC
Thanks for your comment!

Automatically switching the status of this bug to REPORTED so that the KDE team
knows that the bug is ready to get confirmed.

In the future you may also do this yourself when providing needed information.
Comment 4 Tiar 2020-01-16 22:18:30 UTC
@Kruthers do you experience bug 414576 as well? If so, can you please answer Dmitry's question, that is, do you have View -> Instant Preview option turned on or off?
Comment 5 Kruthers 2020-01-17 01:22:09 UTC
@Tymond - It appears to make no difference; I see the same freezing effect with instant preview on or off.

And no, I do NOT seem to experience the bug in that other ticket.  I have zoom bound differently (CTRL-middle mouse drag) but that shouldn't matter.  I do see some difference with instant preview on/off though; zooming is chunkier, and pauses for a fraction of a second here and there w/ instant preview on, and is smoother when off.  But it's not serious.
Comment 6 Kruthers 2020-01-17 01:28:34 UTC
BTW, while testing just now I noticed something; the brush size freezing seems to be caused by the type of brush.  Some of the brushes don't have the glitch at all, and some have it but not as bad:

b)_Basic-1:  no glitch at all, resizes smoothly
b)_Airbrush_Soft: bad glitch, freezes for a long time as size gets large
y)_Texture_Large_Splat: moderate glitch; freezes for only a few seconds when large

Most of the brushes are like Airbrush Soft; the glitch causes freezing for a long time.

Hope you guys can recreate this; I have to stick with 4.2.7 for now.  If there's anything else you want me test just ask.  Thanks!
Comment 7 Kruthers 2020-01-17 01:31:15 UTC
Sorry for multiple comments...  I forgot to mention that I tried all options for "Outline Shape" under Configure Krita -> General -> Cursor, and it made no difference.
Comment 8 Tiar 2020-01-17 01:32:44 UTC
@Kruthers Thanks! With Airbrush_Soft I can reproduce it as well. Thank you so much for this observation, will help immensely :)
Comment 9 Kruthers 2020-01-17 02:37:46 UTC
Excellent, thanks for looking into it!
Comment 10 Tiar 2020-01-20 14:48:07 UTC
Git bisect points to this commit:

tymon@yoga ~/devsec/krita ((no branch, bisect started on 5c6213e04c)) $ git bisect bad
34f3a4a815b3e489eeb4397045738eb2aa74e2d8 is the first bad commit
commit 34f3a4a815b3e489eeb4397045738eb2aa74e2d8
Author: Dmitry Kazakov <dimula73@gmail.com>
Date:   Tue Oct 8 21:13:10 2019 +0300

    Refactor signal compressor to have better timing properties
    
    * before: emits signals with time range [1.0...2.0] * interval
    * after: emits signals with time range [0.5...1.5] * interval
    
    Bascially, now it handles it much better when interval is around
    10-20 ms. With the old version it caused KisCanvas2 to drop frames
    and look ugly when the user pans the canvas.
    
    CCBUG:409460
    
    # Conflicts:
    #       libs/global/tests/CMakeLists.txt

:040000 040000 6fc3790e429be8218d33ac96d7774b373ebf03a2 d4ec7f7d30cb7e34ac05bfb91e612a02d1207503 M	libs
Comment 11 Dmitry Kazakov 2020-01-20 14:52:51 UTC
It must be related to https://bugs.kde.org/show_bug.cgi?id=414576
Comment 12 Dmitry Kazakov 2020-01-31 14:08:03 UTC
Git commit 0ca332c7089c690a62c6d7b66515fe9aacdabbdb by Dmitry Kazakov.
Committed on 31/01/2020 at 14:06.
Pushed by dkazakov into branch 'master'.

Fix hiccups when doing canvas actions

Fixed KisSignalCompressor became too precise and tries to keep
the interval too hard. Sometimes the signal handler is too slow, in
such cases we should still give some time for event loop to execute.

To achieve that, KisSignalCompressor now has an additional operational
mode: "additive interval mode". When this mode is active, then interval
time is counted from the moment, when the execution path is returned from
the signal handler. In "precise interval mode" (default), in reverse, the
interval is counted from the moment, when start() signal arrives.
Related: bug 414576
CC:kimageshop@kde.org

M  +23   -3    libs/global/kis_signal_compressor.cpp
M  +7    -0    libs/global/kis_signal_compressor.h
M  +36   -4    libs/global/tests/KisSignalCompressorTest.cpp
M  +2    -0    libs/global/tests/KisSignalCompressorTest.h
M  +3    -1    libs/ui/input/kis_input_manager_p.cpp

https://invent.kde.org/kde/krita/commit/0ca332c7089c690a62c6d7b66515fe9aacdabbdb
Comment 13 Dmitry Kazakov 2020-01-31 14:15:18 UTC
Git commit 06cb53798c1c6ac69d28b3d280b86513424c6923 by Dmitry Kazakov.
Committed on 31/01/2020 at 14:14.
Pushed by dkazakov into branch 'krita/4.2'.

Fix hiccups when doing canvas actions

Fixed KisSignalCompressor became too precise and tries to keep
the interval too hard. Sometimes the signal handler is too slow, in
such cases we should still give some time for event loop to execute.

To achieve that, KisSignalCompressor now has an additional operational
mode: "additive interval mode". When this mode is active, then interval
time is counted from the moment, when the execution path is returned from
the signal handler. In "precise interval mode" (default), in reverse, the
interval is counted from the moment, when start() signal arrives.
Related: bug 414576
CC:kimageshop@kde.org

M  +23   -3    libs/global/kis_signal_compressor.cpp
M  +7    -0    libs/global/kis_signal_compressor.h
M  +36   -4    libs/global/tests/KisSignalCompressorTest.cpp
M  +2    -0    libs/global/tests/KisSignalCompressorTest.h
M  +3    -1    libs/ui/input/kis_input_manager_p.cpp

https://invent.kde.org/kde/krita/commit/06cb53798c1c6ac69d28b3d280b86513424c6923
Comment 14 acc4commissions 2020-02-03 21:35:19 UTC
It is certainly reduced drastically in the latest nightly, but I don't think it's 'fixed' enough to call it so. It still happens when the size goes over 750~850px.
Comment 15 acc4commissions 2020-02-03 21:40:45 UTC
(In reply to acc4commissions from comment #14)
> It is certainly reduced drastically in the latest nightly, but I don't think
> it's 'fixed' enough to call it so. It still happens when the size goes over
> 750~850px.

Although it's fairly usable as it is. For now I'm personally fine if you need to ignore this.
Comment 16 acc4commissions 2020-02-03 21:47:05 UTC
I was wrong. Sorry. It seems to be a different problem and wasn't solved at all. I will write a separated bug report.