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.
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?
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
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.
I can confirm the issue on Linux. I think the issues Manuel noted are related, so no new bug report is needed.
Weird... I've started bisecting, and after a couple of hours, suddenly I cannot reproduce the issue anymore :-(
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.
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).
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
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.)
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
Still happens. (Win7) It's more like flickering now, like the frame is dropping.
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
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.
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.
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
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
It's reduced but still there... (git 02bdc53)
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.)
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