Created attachment 114576 [details] this is how it looks like So, here is two similar bugs related to brush rotation: 1) Rotation with mirror enabled. I guess some of mirrored stamps take rotation info from "original" stroke. Slow strokes works fine while fast strokes looks quite bad. Tested with direction and tilt rotation. Only happens if Precision is less than 5. 2) Brushes with Rotation > Drawing angle + Lock. Seems like rotation doesn't locks from first stamp, I can even rotate it to 180° before locking. Also sometimes it lock very different rotation (examples on the right). Weird part: it happens a lot with horizontal strokes from right to left but rarely in other directions. Even weirder part: seems like this "from right to left" direction related to canvas because if I rotate canvas at 90° it will happens from top to bot (or from bot to top).
Created attachment 114577 [details] example of preset for mirror bug
Created attachment 114578 [details] preset with rotation lock
Could this be the same issue as in https://bugs.kde.org/show_bug.cgi?id=393336 ?
It sounds like the second issue ("Brushes with Rotation > Drawing angle + Lock.") may be a duplicate. As for the first issue, if I understand correctly they're saying when using symmetry occasionally individual brush dabs are rotated incorrectly. I can't reproduce this as my tablet doesn't have rotation support.
Honestly bug 393336 sounds very different from this one. First issue can be reproduced even with mouse. 1) chose some asymmetrical brush tip 2) set precision less that 5 3) enable some rotation dynamics (drawing angle\fade\distance\time, pressure too) 4) enable symmetry (both horizontal and vertical have this problem) 5) make a quick stroke
similar to what radian said, i encountered this bug today. the easiest way to reproduce this is taking a brush from the pixel engine, making it square, lowering the precision and enabling drawing angle->rotation. when you now paint diagonal strokes with mirroring on, you see jittering. i quickly tested this with on the color smudge engine, but the problem doesn't seem to happen there
This bug is different from bug 393336 as it only happens with precision lower than 5. Thanks to the simple instructions its very easy to reproduce and test the bug. I might as well fix it once my list gets shorten.
I have a feeling that I've fixed something like that recently... It might have the fix like I did for ratio in 56199164d821733b79f81fe978ef5d844178e527
I can still reproduce the bug in krita/4.3
Git commit 6b49984f2a04d14a4a04cfae2c61910a1956d1fa by Dmitry Kazakov. Committed on 01/05/2020 at 17:18. Pushed by dkazakov into branch 'krita/4.3'. Fix double-mirrored dabs when painting with precision < 5 Even though KisDabRenderingQueue returns mutable dabs, it doesn't guarantee that they will be unique in the returned list. We should be very careful with them and ensure that we don't mirror the same paint device twice. M +2 -2 libs/image/kis_painter.cc M +1 -1 libs/image/kis_painter.h M +7 -3 libs/image/krita_utils.cpp M +1 -1 libs/image/krita_utils.h M +14 -2 plugins/paintops/defaultpaintops/brush/kis_brushop.cpp https://invent.kde.org/kde/krita/commit/6b49984f2a04d14a4a04cfae2c61910a1956d1fa
Git commit ae915410fea8ce5a6024689dd19df763b08386d4 by Dmitry Kazakov. Committed on 01/05/2020 at 17:18. Pushed by dkazakov into branch 'master'. Fix double-mirrored dabs when painting with precision < 5 Even though KisDabRenderingQueue returns mutable dabs, it doesn't guarantee that they will be unique in the returned list. We should be very careful with them and ensure that we don't mirror the same paint device twice. M +2 -2 libs/image/kis_painter.cc M +1 -1 libs/image/kis_painter.h M +7 -3 libs/image/krita_utils.cpp M +1 -1 libs/image/krita_utils.h M +14 -2 plugins/paintops/defaultpaintops/brush/kis_brushop.cpp https://invent.kde.org/kde/krita/commit/ae915410fea8ce5a6024689dd19df763b08386d4