Created attachment 122549 [details] video file showing the bug SUMMARY When resizing vector shapes or group pf vector shapes with the Select Shape Tool, gives a very choppy preview while we transform, the shape shown on canvas switches between current position and original position thus making it flicker and choppy. I am attaching a video to describe the bug STEPS TO REPRODUCE 1. Open Krita and create a new vector layer, Create a filled rectangle shape 2. Choose the shape selection tool and try to resize the vector shape you just created OBSERVED RESULT the preview while resizing swithced between new and old position and size EXPECTED RESULT the resize operation should show smooth preview Operating System: Arch Linux KDE Plasma Version: 5.16.5 KDE Frameworks Version: 5.61.0 Qt Version: 5.13.0 Kernel Version: 5.2.13-arch1-1-ARCH OS Type: 64-bit Processors: 8 × Intel® Core™ i7-4790K CPU @ 4.00GHz Memory: 15.6 GiB of RAM
I can confirm this for the latest 4.3.0-prealpha (git e6e9fea) appimage. It also happens in the Sept 6th 4.3.0-prealpha (git ca902a4) appimage This does not happen with 4.2.5 or the 4.2.6 beta-1 appimages.
*** Bug 411853 has been marked as a duplicate of this bug. ***
As per bug 411853 this happens with reference images too.
*** Bug 414336 has been marked as a duplicate of this bug. ***
*** Bug 416172 has been marked as a duplicate of this bug. ***
Git commit 2617900662ff7046d79249077053edc7d6942621 by Dmitry Kazakov. Committed on 24/01/2020 at 14:01. Pushed by dkazakov into branch 'master'. Fix thread-safety for rendering of the shapes Vector shapes are not thread-safe against concurrent read-writes, so we need to utilize rather complicated policy on accessing them: 1) All shape writes happen in GUI thread (right in the tools) 2) No concurrent reads from the shapes may happen in other threads while the user is modifying them. That is why our shape rendering code is split into two parts: 1) First we just fetch a shallow copy of the shapes of the layer (it takes about 1ms for complicated vecotor layers) and pack them into KoShapeManager::PaintJobsList jobs. It happens here, in slotStartAsyncRepaint(), which runs in the GUI thread. It guarantees that noone is accessing the shapes during the copy operation. 2) The rendering itself happens in the worker thread in repaint(). But repaint() doesn't access original shapes anymore. It accesses only they shallow copies, which means that there is no concurrent access to anything (*). (*) "no concurrent access to anything" is a rather fragile term :) There will still be concurrent access to it, on detaching... But(!), when detaching, the original data is kept unchanged, so "it should be safe enough"(c). Especially if we guarantee that rendering thread may not cause a detach (?), and the detach can happen only from a single GUI thread. M +19 -0 libs/flake/KoShape.cpp M +1 -1 libs/flake/KoShape.h M +66 -5 libs/flake/KoShapeManager.cpp M +53 -0 libs/flake/KoShapeManager.h M +15 -0 libs/image/krita_utils.cpp M +1 -0 libs/image/krita_utils.h M +105 -50 libs/ui/flake/kis_shape_layer_canvas.cpp M +1 -0 libs/ui/flake/kis_shape_layer_canvas.h https://invent.kde.org/kde/krita/commit/2617900662ff7046d79249077053edc7d6942621
Should be fixed after this merge: https://invent.kde.org/kde/krita/merge_requests/194