Created attachment 131361 [details] Bug demonstration - what happened to the offset value!? I've attached a sample file so that no one has to recreate it from scratch. Basically, it is a file created using 4.3 that is not being read correctly by git master. In the upper layer, there are a few frames moved using the Move tool, which opening the file in 4.3 clearly shows. Opening the same file in the git master ignores "offset" values per animation frame, and they stay visually in place. P.S. Initially I discovered the issue by having some cropped anim frames of a totally unrelated much bigger project showing at 0,0 position after opening in git master. Hopefully, it's the same issue...
Created attachment 131399 [details] Simple test animation I can confirm this for the Sep03 5.0.0 prealpha (git 9d61e26) appimage. It does not happen with the Sep01 5.0.0 prealpha (git 65a1dec) appimage or with the Sep02 4.4.0 alpha (git 6f6fdcf) appimage (or the 4.3.0 appimage). Tested with an independently made, simple animation, BlueMove.kra attached
Git commit d4b34d1809d5daae4f51b5ea0fba841e33e453eb by Eoin O'Neill. Committed on 08/09/2020 at 18:33. Pushed by eoinoneill into branch 'master'. Fixed offset not being loaded correctly when loading keyframe data. Regression. Interface could be made cleaner by allowing offset assignments to happen through KisRasterKeyframe interface. M +8 -3 libs/image/kis_raster_keyframe_channel.cpp https://invent.kde.org/graphics/krita/commit/d4b34d1809d5daae4f51b5ea0fba841e33e453eb
Sorry about that, I must have missed the assignment when rewriting the load methods. This should correct the offset issues on keyframes.
Preliminary testing shows that the issue is gone. Just for note - I just opened one file where it was messed up. It isn't even one of the attached. Sorry for that.
*** Bug 426524 has been marked as a duplicate of this bug. ***