| Summary: | Anim: Can't scrub animation back to starting frame when re-selecting it after pausing. | ||
|---|---|---|---|
| Product: | [Applications] krita | Reporter: | zane.zaccagni |
| Component: | Animation | Assignee: | Krita Bugs <krita-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | minor | CC: | emmetoneill.pdx |
| Priority: | NOR | ||
| Version First Reported In: | 5.2.9 | ||
| Target Milestone: | --- | ||
| Platform: | Microsoft Windows | ||
| OS: | Microsoft Windows | ||
| Latest Commit: | https://invent.kde.org/graphics/krita/-/commit/0316f63a970191a421d5c34bdedd9774d674193b | Version Fixed/Implemented In: | |
| Sentry Crash Report: | |||
| Attachments: | Bug in question | ||
|
Description
zane.zaccagni
2025-03-01 10:36:23 UTC
Hi Zane, When you say the canvas is freezing, do you mean that you are drawing on the frame but not seeing the new lines? Are you able to reproduce this bug consistently, or is it kind of random when it happens? As of now, I'm not able to reproduce this issue on my end (git master) even with "cached frame size limit" set as low as possible. I'm still able to play, pause, stop and then continue drawing without having any issues with the canvas. If there is any more info you can share (more detailed steps to reproduce, a video recording, a test file, etc.) about what this bug looks like or how to reproduce it, please let us know and I'll take another look at it. Emmet Created attachment 179197 [details]
Bug in question
(In reply to zane.zaccagni from comment #0) > SUMMARY > Exceeding cached frame size limit freezes canvas display after playing > animation. > > STEPS TO REPRODUCE > 1. Check "Limit cached frame size" > 2. Lower the amount of pixels for "Limit cached frame size limit" > 3. Add two frames in animation timeline > 4. Play animation > 5. Pause or Stop animation > > OBSERVED RESULT > The Canvas freezes on the frame that was stopped on, but you can still draw > on it. > > EXPECTED RESULT > The Canvas not freezing. > The Canvas displaying correctly to the highlighted frame. > > SOFTWARE/OS VERSIONS > Windows: 10.0.19045 Build 19045 > > ADDITIONAL INFORMATION It is Consistent. 🐛🧹 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. Ok, your video has helped me see the problem, thanks! I can confirm the bug now. To clarify the bug (for my own sake later): The problem seems to be that you can no longer re-select the animation starting frame by clicking on it once the animation has been paused. This is likely because re-selection of the currently selected frame is filtered out somewhere. This behavior doesn't seem to depend on cache size at all, and I seem to be able to reproduce it without cache limits. Temporary workarounds: 1. Clicking on the frames/timing header (above the frame table) works as expected and allows you to refresh the frame selection. 2. Hitting the stop button a second time will reset the animation back to the first frame. (I'll be renaming this bug.) Git commit c65f656e1287620d7f9466a4a4f0e3ab8503808f by Emmet O'Neill. Committed on 01/04/2025 at 21:19. Pushed by emmetoneill into branch 'master'. UI/Animation/TimelineDocker: Can now re-select previous selected frame after pausing. The default behavior of QAbstractItemModel was causing an edge case where users couldn't re-select the starting frame of their animation after pausing because it was technically already paused. Now, we've made it so that pausing the animation playback will move the selection to the frame that the animation was paused on, solving this issue. M +6 -3 libs/ui/KisPlaybackEngine.cpp M +1 -0 libs/ui/KisPlaybackEngineQT.cpp M +26 -2 plugins/dockers/animation/KisAnimTimelineDocker.cpp M +1 -0 plugins/dockers/animation/KisAnimTimelineDocker.h M +0 -2 plugins/dockers/animation/KisAnimTimelineFramesView.cpp https://invent.kde.org/graphics/krita/-/commit/c65f656e1287620d7f9466a4a4f0e3ab8503808f Git commit 0316f63a970191a421d5c34bdedd9774d674193b by Emmet O'Neill. Committed on 04/09/2025 at 22:59. Pushed by emmetoneill into branch 'master'. UI/Animation/TimelineDocker: Can now re-select previous selected frame after pausing. The default behavior of QAbstractItemModel was causing an edge case where users couldn't re-select the starting frame of their animation after pausing because it was technically already paused. Now, we've made it so that pausing the animation playback will move the selection to the frame that the animation was paused on, solving this issue. M +6 -3 libs/ui/KisPlaybackEngine.cpp M +1 -0 libs/ui/KisPlaybackEngineQT.cpp M +26 -2 plugins/dockers/animation/KisAnimTimelineDocker.cpp M +1 -0 plugins/dockers/animation/KisAnimTimelineDocker.h M +0 -2 plugins/dockers/animation/KisAnimTimelineFramesView.cpp https://invent.kde.org/graphics/krita/-/commit/0316f63a970191a421d5c34bdedd9774d674193b Git commit ef74e03a4058953926971d2177f3164e3b51770f by Emmet O'Neill. Committed on 04/09/2025 at 23:46. Pushed by emmetoneill into branch 'master'. Animation/Audio: Fixed playback when audio is attached. The bugfix associated with commit 0316f63a970191a421d5c34bdedd9774d674193b inadvertently broke animation playback after audio was attached due to a 2x signal/slot connection causing the play/pause button to activate twice upon switching to the PlaybackEngineMLT. Switching the connections between the transport controls and playback engine to use Qt::UniqueConnection fixes this problem. M +8 -8 plugins/dockers/animation/KisAnimTimelineDocker.cpp https://invent.kde.org/graphics/krita/-/commit/ef74e03a4058953926971d2177f3164e3b51770f |