Bug 410158 - Severe lag in 4.3.0 pre-alpha Brush Editor when adjusting transfer curves
Summary: Severe lag in 4.3.0 pre-alpha Brush Editor when adjusting transfer curves
Status: RESOLVED FIXED
Alias: None
Product: krita
Classification: Applications
Component: Brush engines (show other bugs)
Version: nightly build (please specify the git hash!)
Platform: Debian stable Linux
: NOR normal
Target Milestone: ---
Assignee: Dmitry Kazakov
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-07-24 13:09 UTC by Ahab Greybeard
Modified: 2019-09-21 12:09 UTC (History)
7 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
Brush preset examples for brush editor lag (219.16 KB, application/zip)
2019-07-25 11:05 UTC, Ahab Greybeard
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ahab Greybeard 2019-07-24 13:09:56 UTC
SUMMARY
This happens in the 4.3.0 pre-alpha appimages and does not happen in the 4.2.3 and previous appimages (but see Additional Notes). In the Windows portable packages, the effect is there but is not as severe as in the appimages. It's not a function breaker but it is an unpleasant user experience.

STEPS TO REPRODUCE
1. Open the Brush Editor, select a property page such as Size and adjust the transfer curve by grabbing and dragging an end point.

OBSERVED RESULT
1. There is notable lag in the movement of the point.

EXPECTED RESULT
It should respond as quickly as it does in 4.2.3 and previous versions.

SOFTWARE/OS VERSIONS
Krita

 Version: 4.3.0-prealpha (git 600ee12)
 Languages: en_GB, en
 Hidpi: true

Qt

  Version (compiled): 5.12.4
  Version (loaded): 5.12.4

OS Information

  Build ABI: x86_64-little_endian-lp64
  Build CPU: x86_64
  CPU: x86_64
  Kernel Type: linux
  Kernel Version: 4.19.0-5-amd64
  Pretty Productname: Debian GNU/Linux 10 (buster)
  Product Type: debian
  Product Version: 10

Hardware Information

  GPU Acceleration: auto
  Memory: 16039 Mb
  Number of Cores: 8
  Swap Location: /tmp

ADDITIONAL INFORMATION
The effect is more severe with a brush preset that has more properties active. In one particular case, with the latest 4.3.0 pre-alpha appimage, I had to wait 5 seconds for an endpoint to respond to dragging. This only took about a second with 4.2.3. For a simple brush such as Basic_Opacity, the effect is not as bad but it is still worse in the 4.3.0 pre-alpha appimages than previous versions.

In case it was related to my recent update to Debian 10, I went back to Debian 9 and the effect was still there, just as bad.

Windows portable packages show the lag in the 4.3.0 pre-alpha, compared to the 4.2.3 version, but it is much less severe than with the appimages.
Comment 1 vanyossi 2019-07-25 00:50:45 UTC
Im having difficulties reproducing this behaviour. all brushes react in the same speed.

Could you share a preset (either by name, or attaching if its a custom) you know its best to show this?
Comment 2 M 2019-07-25 10:39:10 UTC
I can confirm this on my master build. Not only the curves are affected, but any slider throughout the brush settings I tested can produce severe slowdown, increasingly so the longer I keep dragging the slider. Maybe it's something to do with signal compressors?

Almost any brush preset and engine I tested was affected and I was able to provoke 10+ seconds freezes with a Filter Engine brush. However, the Clone Engine wasn't affected (at least not noticeably), which might be because it doesn't create a preview.

In the Brush Tip section I noticed that while moving the sliders with Predefined and Text tips causes the lag, for Auto tips the brush preview only updates once I let go of the slider.

Should I create a separate bug report for the described problems?

 Version: 4.3.0-prealpha (git 600ee12)
 Languages: en_US
 Hidpi: true

Qt

  Version (compiled): 5.13.0
  Version (loaded): 5.13.0

OS Information

  Build ABI: x86_64-little_endian-lp64
  Build CPU: x86_64
  CPU: x86_64
  Kernel Type: linux
  Kernel Version: 5.2.2-1-MANJARO
  Pretty Productname: Manjaro Linux
  Product Type: manjaro
  Product Version: unknown


Hardware Information

  GPU Acceleration: auto
  Memory: 15950 Mb
  Number of Cores: 8
  Swap Location: /tmp
Comment 3 Ahab Greybeard 2019-07-25 11:05:58 UTC
Created attachment 121721 [details]
Brush preset examples for brush editor lag

I attach three brush presets and a .gih brush tip (which is used by two of them) as examples.

It does seem that updating the brush stroke preview is a significant factor in the lag. A complex .gih brush and many control parameters being active leads to more lag.

I've tried these with a recent 4.3.0 pre-alpha portable .zip on Windows 10 and the lag is much smaller than with an appimage on Linux.

On Linux, the difference between 4.2.3 and 4.3.0 is severe.
Comment 4 Halla Rempt 2019-07-25 11:20:35 UTC
I can confirm the issue on Linux. I think the issues Manuel noted are related, so no new bug report is needed.
Comment 5 Halla Rempt 2019-07-25 12:44:00 UTC
Weird... I've started bisecting, and after a couple of hours, suddenly I cannot reproduce the issue anymore :-(
Comment 6 Raghavendra kamath 2019-08-22 16:01:51 UTC
I can confirm the issue and I think enabling pattern gives a good probability to reproduce the issue. My wild guess would be that the brush preview that gets generated is the reason for this lag.
Comment 7 Ahab Greybeard 2019-09-11 18:51:57 UTC
Note: This does not happen in the recent 4.2.6 appimage formal release but it still happens in the latest 4.3.0 pre-alpha appimage (git aa34d6d).
Comment 8 Tiar 2019-09-11 19:40:02 UTC
Ahab: can you please check if there is a difference now between Krita Next (unstable/master) and Krita Plus (stable, should be the same as formal release + a few more commits)? It sounds weird to me since I was working on curves recently and I don't remember any commits that went into the release but weren't on master, too.

In any case, I believe this bug should be solved in this MR: https://invent.kde.org/kde/krita/merge_requests/121
Comment 9 Ahab Greybeard 2019-09-11 21:33:47 UTC
Krita Stable 4.2.6 appimage #491 Sep 11 (git f86e9ee) does not show lag on curve or slider adjustment.

Krita Next/Nightly 4.3.0 pre-alpha appimage #619 Sep 11 (git aa34d6d) shows lag of about 5 seconds on curve and slider adjustment.

The 4.2.6 beta-1 that I've had since it was released does not show lag.

(This seems strange.)
Comment 10 Tiar 2019-09-13 23:24:05 UTC
Git commit 542da22bbbdcdb68e015bdb3b47e3f46c83c6214 by Agata Cacko.
Committed on 13/09/2019 at 23:23.
Pushed by tymond into branch 'master'.

Fix curve changing with sensors w/ Use Same Curve

Before this commit, curve would change semi-randomly in some cases
if you change from some specific sensors to some other specific sensors
(having a complex curve and clicking randomly should show a bug though)
when "Share curve across all settings" is selected.
This commit fixes that behaviour.
Related: bug 383909

M  +3    -3    libs/global/kis_signal_compressor.h
M  +18   -1    libs/ui/widgets/kis_curve_widget.cpp
M  +17   -0    libs/ui/widgets/kis_curve_widget.h
M  +6    -2    libs/ui/widgets/kis_curve_widget_p.h
M  +4    -0    plugins/paintops/libpaintop/kis_auto_brush_widget.cpp
M  +27   -22   plugins/paintops/libpaintop/kis_curve_option.cpp
M  +6    -2    plugins/paintops/libpaintop/kis_curve_option.h
M  +35   -15   plugins/paintops/libpaintop/kis_curve_option_widget.cpp
M  +5    -2    plugins/paintops/libpaintop/kis_curve_option_widget.h

https://invent.kde.org/kde/krita/commit/542da22bbbdcdb68e015bdb3b47e3f46c83c6214
Comment 11 acc4commissions 2019-09-14 09:55:38 UTC
Still happens. (Win7) It's more like flickering now, like the frame is dropping.
Comment 12 Tiar 2019-09-14 15:26:23 UTC
Git commit a2a86bd9a7c0c595fa6f7e6a7bcfb44144c00e4c by Agata Cacko.
Committed on 14/09/2019 at 15:25.
Pushed by tymond into branch 'krita/4.2'.

Fix curve changing with sensors w/ Use Same Curve

Before this commit, curve would change semi-randomly in some cases
if you change from some specific sensors to some other specific sensors
(having a complex curve and clicking randomly should show a bug though)
when "Share curve across all settings" is selected.
This commit fixes that behaviour.
Related: bug 383909

M  +3    -3    libs/global/kis_signal_compressor.h
M  +18   -1    libs/ui/widgets/kis_curve_widget.cpp
M  +17   -0    libs/ui/widgets/kis_curve_widget.h
M  +6    -2    libs/ui/widgets/kis_curve_widget_p.h
M  +4    -0    plugins/paintops/libpaintop/kis_auto_brush_widget.cpp
M  +27   -22   plugins/paintops/libpaintop/kis_curve_option.cpp
M  +6    -2    plugins/paintops/libpaintop/kis_curve_option.h
M  +35   -15   plugins/paintops/libpaintop/kis_curve_option_widget.cpp
M  +5    -2    plugins/paintops/libpaintop/kis_curve_option_widget.h

https://invent.kde.org/kde/krita/commit/a2a86bd9a7c0c595fa6f7e6a7bcfb44144c00e4c
Comment 13 Ahab Greybeard 2019-09-15 09:13:29 UTC
Krita 4.3.0 pre-alpha #622 Sep14 (git 68fe323) does not show lag when dragging a point on an adjustment curve.
It does show lag when dragging a slider. This is not too bad on a simple brush preset but can be significant on a complicated brush preset, e.g one with a pattern set active and more parameters active.
However, you can click on the slider instead of dragging it to set a value and the response to point clicks on the sliders is good. From the point of view of practical use, it seems much better and almost fully solved. 

This bug was reported against the 4.3.0 pre-alpha at a time when 4.2.3 was the formal release and 4.2.3 did not have the bug.
I've just noticed (because I've only just checked) that 4.2.4, 4.2.5, 4.2.6 beta-1 (and 4.2.6) appimages do not show the bug. It seems to have been present only in the 4.3.0 pre-alphas.
Comment 14 acc4commissions 2019-09-15 09:40:12 UTC
Bugs are in both 4.2.6, 4.3.0 pre-alphas here. It's slightly better in 4.3.0 pre-alphas than 4.2.6. 

It doesn't happen when I'm dragging the silders in 'Brush Tip', but happens with any other sliders in other options.
Comment 15 M 2019-09-15 11:50:11 UTC
I finished bisecting when the slowdown first started, the result is:

commit bbc0f80732afbf0cb36ccdf5fd6b672dd15712a6
Author: Dmitry Kazakov <dimula73@gmail.com>
Date:   Fri Jul 12 20:02:22 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
Comment 16 Dmitry Kazakov 2019-09-16 14:38:09 UTC
Git commit fef9ff850aa25ba67cceafac60cf99cd7b79f6e1 by Dmitry Kazakov.
Committed on 16/09/2019 at 14:37.
Pushed by dkazakov into branch 'master'.

Fix freezes when changing brush properties/curves

This patch basically makes brush preview to be calculated asynchronously
in a separate worker thread and update preview only on a completion-signal
arrival.

WARNING: this patch can theoretically cause a bug, which will make
         the strokes on canvas be painted in extremely small size
         (< 25px). If it happens, then originalPresetSize recovering
         should be restored.

M  +1    -1    libs/image/brushengine/kis_paintop_config_widget.cpp
M  +1    -1    libs/image/brushengine/kis_paintop_preset.cpp
M  +1    -1    libs/ui/widgets/kis_paintop_presets_popup.cpp
M  +63   -27   libs/ui/widgets/kis_preset_live_preview_view.cpp
M  +8    -1    libs/ui/widgets/kis_preset_live_preview_view.h

https://invent.kde.org/kde/krita/commit/fef9ff850aa25ba67cceafac60cf99cd7b79f6e1
Comment 17 acc4commissions 2019-09-17 09:31:48 UTC
It's reduced but still there... (git 02bdc53)
Comment 18 Ahab Greybeard 2019-09-17 11:36:14 UTC
With both the 4.3.0-prealpha (git 71126cc) appimage and the 4.3.0-prealpha (git 02bdc53) portable .zip, I find the sliders and the curves have no lag even if I activate lots of parameters and control inputs and share the curve across settings.

(My PC and graphics card are not particularly modern or powerful.)
Comment 19 Dmitry Kazakov 2019-09-21 12:09:07 UTC
Git commit 61462209126d6b70195da80f94893faa4cfb5943 by Dmitry Kazakov.
Committed on 21/09/2019 at 10:02.
Pushed by dkazakov into branch 'krita/4.2'.

Fix freezes when changing brush properties/curves

This patch basically makes brush preview to be calculated asynchronously
in a separate worker thread and update preview only on a completion-signal
arrival.

WARNING: this patch can theoretically cause a bug, which will make
         the strokes on canvas be painted in extremely small size
         (< 25px). If it happens, then originalPresetSize recovering
         should be restored.

M  +1    -1    libs/image/brushengine/kis_paintop_config_widget.cpp
M  +1    -1    libs/image/brushengine/kis_paintop_preset.cpp
M  +1    -1    libs/ui/widgets/kis_paintop_presets_popup.cpp
M  +63   -27   libs/ui/widgets/kis_preset_live_preview_view.cpp
M  +8    -1    libs/ui/widgets/kis_preset_live_preview_view.h

https://invent.kde.org/kde/krita/commit/61462209126d6b70195da80f94893faa4cfb5943