SUMMARY The animation cache for an affected layer does not get invalidated by a certain sequence of undo, play, and redo operations. STEPS TO REPRODUCE 1. Create a new document. 2. Create some frames on a layer and draw something in them. 3. Draw one extra mark in any frame. 4. Undo (animation cache for drawn on frame is invalidated (expected)) 5. Play (animation cache is updated for the invalidated frame, the extra mark is gone (expected)) 6. Redo (animation cache is not invalidated for the frame that was affected by redo (unexpected)) 7. Play (animation cache is not changed, the extra mark is still gone (unexpected)) OBSERVED RESULT The animation played is using stale cache data. EXPECTED RESULT The animation played is using updated cache data (redo should invalidate the affected frames). SOFTWARE/OS VERSIONS Operating System: NixOS 25.11 KDE Plasma Version: 6.4.5 KDE Frameworks Version: 6.19.0 Qt Version: 6.9.2 Kernel Version: 6.17.1-zen1 (64-bit) Graphics Platform: X11 Processors: 24 × AMD Ryzen 9 3900X 12-Core Processor Memory: 64 GiB of RAM (62.7 GiB usable) Graphics Processor: AMD Radeon RX 7900 XTX
Hey again, cromachina. Thanks for the detailed bug report. I'm not able to reproduce this issue on the latest master version (git f6a483e279ee1b1616b05b91e78c92b097b2f047) on my Linux system. In my testing I made a animation of the numbers 1-10, played it, added a stray line to the number 3, played it again, undid that line, and then played it again, and the cache cleared and regenerated as expected. If you have time, can you test the latest nightly "Krita Next" appimage?
I'm setting this as "needsinfo" "worksforme" for now. (Don't mind the somewhat dismissive-sounding label. We appreciate the report! lol)
I tested again on 5.3.0-prealpha (git f6a483e) and verified that it seems to be resolved there!
🐛🧹 Thanks for your comment! Automatically switching the status to REPORTED so the team can perform further triage. In the future you may also do this yourself when providing needed information.