In Krita 3.0 Beta, when Instant preview is enabled, Ctrl+LMB to pick color is not very responsive. I often need to keep Ctrl+LMB pressed down, wait for a second until a new color is picked. This pretty much makes Ctrl+LMB color picking useless. It gets more obvious when: 1) the picture is big; 2) a big brush stroke was just applied (and probably still not finish drawing); 3) a brush stroke was just undone. It feels like Qt OpenGL queue congestion to me. Instant Preview is causing so much problem now: 1) Undo/Redo has visual glitches; 2) This bug; 3) Overall slowdown and more. Are these normal by design for enabling instant preview? Or they are issues to be addressed? Reproducible: Always
Hi, Tyson! I cannot reproduce exactly the same issue as you describe with Ctrl+LMB. I mean whatever I do, Ctrl+LMB work almost instantly. So I would really appreciate a video or a preset + image size configuration for the test case. Though I have found two other issues: 1) When a slow brush is being recalculated, you cannot use Ctrl+Z until the background stroke is completed. You can only press Esc to cancel all the uncompleted strokes. I can fix it in this way: pressing Ctrl+Z while background strokes are being recalculated cancels all of them. Canceling only the latest stroke might be a bit complicated job. Is it ok if Ctrl+Z will cancel all the background strokes or you'd still prefer if it undone the latest stroke only? 2) If you press Esc and start painting without waiting for the update process to finish you'll get artifacts. That is a bug and I'm going to fix that.
Created attachment 98831 [details] Krita 3.0 beta Instant Preview related Ctrl Color picking issue video
Created attachment 98832 [details] Krita 3.0 beta Instant Preview related Ctrl Color picking issue test file
It probably has something to do with the size of the document. It happened to a 5500x6000px, 3 layers, 500M memory usage document. Maybe not the first few picking, but the picking will fail after a few strokes.
Created attachment 98833 [details] Krita 3.0 beta Instant Preview drawing artifact Apparently, it was not an Undo/Redo related artifact, it's a canvas drawing artifact. As you can see in this video, Instant Preview is actually making the canvas drawing much slower. The progress bar took seconds to finish. When I turn Instant Preview OFF, then there is no delay at all.
Hi, Tyson! I have managed to reproduce the Color Picking bug and I am going to fix it now. But I cannot understand your latest video? What exactly is the bug? Your preview stroke was rather quick and the background stroke finished in a reasonable time. What exactly is the problem? I mean this video: https://bugs.kde.org/attachment.cgi?id=98833
Git commit 2f5d2bc4ee1282f0b411a0a25982e7e8700f7181 by Dmitry Kazakov. Committed on 12/05/2016 at 13:28. Pushed by dkazakov into branch 'master'. Fix color picking lag and a crash when picking color right after Undo 1) The connection between two strategies should be Direct, because the Lod0 strategy doesn't have an event queue. 2) Pick the color all the time, even when the mouse button is already released 3) Update the color when the preview is shown, not when the stroke is active. Fixes T2435 M +2 -2 libs/ui/tool/kis_tool_paint.cc M +2 -1 libs/ui/tool/strokes/kis_color_picker_stroke_strategy.cpp http://commits.kde.org/krita/2f5d2bc4ee1282f0b411a0a25982e7e8700f7181
Hi, Tyson! The original bug is now finished! The issues with artifacts mentioned in the original report are also finished. Please report the issue with video [0] as a separate bug (if it is still a bug). And try to explain what the problem is :) The only trouble I can see is canvas flickering when the original stroke is completed execution, which is already reported in bug 361448 [1]. [0] - https://bugs.kde.org/attachment.cgi?id=98833 [1] - https://bugs.kde.org/show_bug.cgi?id=361448
Thank you, Dmitry! :D