Created attachment 149753 [details] test file SUMMARY When a transform mask is animated with animation curves, resizing the canvas of the document will cause the animated transform mask to behave erratically. STEPS TO REPRODUCE 1. Open the test file 2. Resize canvas with the anchor *not* set to top-left corner (either increase or decrease the canvas size can do) OBSERVED RESULT The layer with the animated transform mask vanishes from the canvas area, and the values in the curves docker are still showing the old values. EXPECTED RESULT The animation curves should be adjusted according to the canvas resize operation. SOFTWARE/OS VERSIONS Windows: Windows 10 ADDITIONAL INFORMATION Nightly b846a63f2a (stable)
Git commit 4fbf6d6dc2ed4dd54bf3edf2755e52d54082516f by Eoin O'Neill. Committed on 16/06/2022 at 03:17. Pushed by eoinoneill into branch 'master'. Animated Transforms now respect cropping translations. NOTE: I'm not happy with how the translation is working as a whole with transform masks after cropping. E.G. In Alvin's test image, the circle drawn is roughly 512px units into the canvas. By that logic, cropping the image should actually move the existing transform keys to near 0 value. However, the actual translation is by roughly 3000 units. This looks correct visually, but the coordinates make no sense. I'll file this as a separate bug. It's not **majorly** important, but it would be nice to have logical coordinates for a transformation masks. I think this bug is there on the base transformation mask, but isn't easily noticable until you have an animated transform mask on where the translation values suddenly matter more. M +19 -0 plugins/tools/tool_transform2/kis_animated_transform_parameters.cpp M +3 -0 plugins/tools/tool_transform2/kis_animated_transform_parameters.h https://invent.kde.org/graphics/krita/commit/4fbf6d6dc2ed4dd54bf3edf2755e52d54082516f
If possible, I'd like this new behaviour to be an option, maybe a 'hidden' option in kritarc (to avoid the 'option forest' problem). Even with a small and simple animated transform mask, if I Resize Canvas then there is lock up for a long time with no indication of what is happening except high CPU usage in the system monitior. Even after the resize has been done, the resulting animation is not repositioned as might be expected anyway. I'm used to Resizing between a 'large' size for off-canvas content development and a smaller 'final' size for animated transform mask manipulation and rendering out. This change makes canvas size switching a very inconvenient thing.
Git commit ea817fb6418c4866712ac88288113f8b6d2d3b3e by Emmet O'Neill, on behalf of Eoin O'Neill. Committed on 21/06/2022 at 03:02. Pushed by emmetoneill into branch 'krita/5.1'. Animated Transforms now respect cropping translations. NOTE: I'm not happy with how the translation is working as a whole with transform masks after cropping. E.G. In Alvin's test image, the circle drawn is roughly 512px units into the canvas. By that logic, cropping the image should actually move the existing transform keys to near 0 value. However, the actual translation is by roughly 3000 units. This looks correct visually, but the coordinates make no sense. I'll file this as a separate bug. It's not **majorly** important, but it would be nice to have logical coordinates for a transformation masks. I think this bug is there on the base transformation mask, but isn't easily noticable until you have an animated transform mask on where the translation values suddenly matter more. M +19 -0 plugins/tools/tool_transform2/kis_animated_transform_parameters.cpp M +3 -0 plugins/tools/tool_transform2/kis_animated_transform_parameters.h https://invent.kde.org/graphics/krita/commit/ea817fb6418c4866712ac88288113f8b6d2d3b3e
(In reply to Ahab Greybeard from comment #2) > If possible, I'd like this new behaviour to be an option, maybe a 'hidden' > option in kritarc (to avoid the 'option forest' problem). An option might be possible here, but I think I'd prefer to handle that on the next version since we're currently in string freeze. As much as an option forest is a problem, I'm also not sure about burying too many features within the config files as they would still need to be supported and tested, which makes that process more difficult. I don't understand your use-case all that well, and I'm not sure why canvas resizing should cause that much slowdown (since it's basically just math -- the cache reloading would take most of the time but it shouldn't hang the program.) but if you don't mind submitting a new bug report (preferably as wishlist) with an image illustrating the slowdown, that would help. I think we could always treat it as a checkbox option in the crop tool option docker, but at the very least it should apply to all transformation masks (including non-animated) for the sake of consistency.
Wishlist report made: https://bugs.kde.org/show_bug.cgi?id=456134