Created attachment 125512 [details] recording SUMMARY It happens in 4.2.8 and also in the nightly builds. Please watch the recorded video. It's hard to describe. :P STEPS TO REPRODUCE 1. Select anything. 2. Click it with transform tool, and hold the Shift key. 3. Move the cursor around fast and widely. OBSERVED RESULT Offsets and ratio goes wrong. EXPECTED RESULT It should stays the same. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION Even when you don't hold shift and do this, offsets goes wrong.
Should I say 'position' instead of 'offsets'? I'm not sure. But you probably get what I want to say. :P
Created attachment 125520 [details] Bad Transform Effects Screenshots I see this with the Jan 28th appimage git(049dd11). It only happens with a vector shape, not a paint layer content. I attach zipped screenshots a,b,c,d a: Original 600 x 600 square b: Offset/position drift after performing a corner drag with Shift key held. It was necessary to do very rapid sylus movements over a long time to get this. When the transform was finalised with the Return key, the on-screen image returned to its original square appearance. When the transform tool was activated again, the 'b' image reappeared and could be transformed to:- c: Additional stretch of the transform preview. When the transform was finalised with the Return key, the on-screen image returned to its original square appearance. At this stage, the Move tool did not work on the original image. Its bounding box moved but there was no on-screen movement of content or movement when the Return key was pressed. If I drew a green line at the top of the screen then that line did not appear. If I then turned off and then on the layer visibility, I got:- d: A fragment. I saw other fragmentation and artifact effects as I did more messing around but I didn't think it was productive to investigate further at this stage.
(In reply to Ahab Greybeard from comment #2) > I see this with the Jan 28th appimage git(049dd11). > It only happens with a vector shape, not a paint layer content. Well, it happens with paint layer contents here, which makes this a problem.
I misunderstood/misinterpreted what I saw on your video compared to what I was seeing on my screen when doing this in krita. In the tool options docker for the transform tool, there is a small button at the left near the top, called Transform around pivot point. Can you toggle that to see if if makes a difference to the results you get? Your video shows continuous movement of the centre point as a corner is dragged around. I don't get that at all and it may be due to the setting of that small button. What I do get is a small sudden offset of the centre pivot point that happens and increases after repeated rapid dragging of the corner point. I only noticed this after I started looking at vector layers but it does happen on paint layers too (and a ratio change) now that I've gone back to it and moved the cursor faster and further.
(In reply to Ahab Greybeard from comment #4) > In the tool options docker for the transform tool, there is a small button > at the left near the top, called Transform around pivot point. Can you > toggle that to see if if makes a difference to the results you get? It still happens with the option pressed.
I don't have the continuous pivot point (centre point) shift when using Windows 10 unless I have that button pressed (brighter colour) or unless I press and hold the Alt key while dragging a corner around. This is with 4.2.8 and the Feb 04 Nightly portable g8f8b95e82c Either way, there is pivot point offset and aspect ratio change when there should not be and there are other follow-on problems as well.
Still happens in 4.4.1.
Even though I remember trying to fix something like that, the bug is still reproducible :(
Yes, and this still happens in 5.0 alpha.
Git commit d9cfa517328595d3752c7d045114d7d6abb76560 by Dmitry Kazakov. Committed on 25/05/2021 at 13:07. Pushed by dkazakov into branch 'master'. Fix drift of the transformed image when moving mouse too quickly We should use stable base for the iterative search algorithm, not the current state of the args. M +21 -15 plugins/tools/tool_transform2/kis_free_transform_strategy.cpp M +10 -0 plugins/tools/tool_transform2/kis_free_transform_strategy_gsl_helpers.cpp M +2 -0 plugins/tools/tool_transform2/kis_free_transform_strategy_gsl_helpers.h https://invent.kde.org/graphics/krita/commit/d9cfa517328595d3752c7d045114d7d6abb76560
It is fixed, but the transformation itself became very jagged and laggy.
Okay, I'll check. I know what the problem is, but I don't know if I can fix it actually :)
Git commit 9db743c9ed776746e10601b2992372ad6a6ecad0 by Dmitry Kazakov. Committed on 28/05/2021 at 13:27. Pushed by dkazakov into branch 'master'. Fix smoothness of Free Transform mode For the affine transform mode we have an explicit solution for the scale coefficients. M +22 -13 plugins/tools/tool_transform2/kis_free_transform_strategy.cpp M +89 -0 plugins/tools/tool_transform2/kis_free_transform_strategy_gsl_helpers.cpp M +5 -0 plugins/tools/tool_transform2/kis_free_transform_strategy_gsl_helpers.h https://invent.kde.org/graphics/krita/commit/9db743c9ed776746e10601b2992372ad6a6ecad0
Git commit 6b25a2303a49c957fcd1b15a666cdad7d5317918 by Dmitry Kazakov. Committed on 01/06/2021 at 12:11. Pushed by dkazakov into branch 'krita/4.3'. Fix smoothness of Free Transform mode For the affine transform mode we have an explicit solution for the scale coefficients. M +22 -13 plugins/tools/tool_transform2/kis_free_transform_strategy.cpp M +89 -0 plugins/tools/tool_transform2/kis_free_transform_strategy_gsl_helpers.cpp M +5 -0 plugins/tools/tool_transform2/kis_free_transform_strategy_gsl_helpers.h https://invent.kde.org/graphics/krita/commit/6b25a2303a49c957fcd1b15a666cdad7d5317918
Git commit e2e223b4bf1f3c3507682f684053120eebc28f49 by Dmitry Kazakov. Committed on 01/06/2021 at 12:10. Pushed by dkazakov into branch 'krita/4.3'. Fix drift of the transformed image when moving mouse too quickly We should use stable base for the iterative search algorithm, not the current state of the args. # Conflicts: # plugins/tools/tool_transform2/kis_free_transform_strategy.cpp M +22 -16 plugins/tools/tool_transform2/kis_free_transform_strategy.cpp M +10 -0 plugins/tools/tool_transform2/kis_free_transform_strategy_gsl_helpers.cpp M +2 -0 plugins/tools/tool_transform2/kis_free_transform_strategy_gsl_helpers.h https://invent.kde.org/graphics/krita/commit/e2e223b4bf1f3c3507682f684053120eebc28f49