i haven’t been able to find any information on this yet, so here goes:
i’ve noticed for a while that when i export my animation from Krita, it plays faster than krita’s own animation playback in the program. i just saw this today:
is there a way to fix this without this workaround? i have in-memory cache enabled. my specs are ryzen 5600x, rtx 3080, 64gbs of RAM running on a huion 1080p pen display, so i’m pretty sure it’s not a performance issue.
I tested it on my system and I can confirm this is a performance problem.
How big is your animated canvas? I did an attempt with A4 600dpi (which is 7000x5000 resolution) and at 24 FPS speed I was getting an effective 21’ish FPS, same as you. When I animated at 60 FPS, the effective FPS was 19’ish. When I enabled Drop Frames, I was losing about 50% of the frames.
For the next test, I used 1018x720 canvas resolution, still at 60 FPS animation speed and that got me real 60 FPS.
NB: The tooltip is indeed bugged and always shows “Drop Frames (off)”. But the button is accurate. When it turns red, it means it’s dropping frames.
Can you try switching the animation cache to in-memory?
I did this on my system and while I didn’t get full 60 FPS, it was much, much smoother. So it may be just enough to fix your problem. With 7000x5000 canvas Krita consumed 21 GB of RAM, but a more sane resolution should be fine
I’m not sure if Krita can preview the video at a reduced resolution. That would be the next best thing. And naturally, rendering the animation to a file would be the safest way to get an accurate result. Maybe someone else knows better.
Footnote. I’m not an expert on video, but I think this is a performance problem because in Krita we’re dealing with a full-size, uncompressed, and not accelerated frames. On the other hand, the rendered video is optimized for decoding speed and size, and typically is handled by the specialized video acceleration hardware. So it’s not apples to apples.
i already have in-memory cache enabled, as stated earlier. i typically use the Japanese Animation template when i’m animating (1756 x 1240) before upscaling to a higher resolution (4k+) for cleanup. on both resolutions i experience the same issue. i would like to know what causes this, as it is not something i experience in the other software i use, tahoma2d. as far as i can tell, what you see is what you get there, even before it caches whatever effects one may use in compositing, for playback.
Oh, sorry, I missed the detail about the in-memory cache…
Thank you for specifying the resolution, this is very helpful. OK, In this case I agree this must be something else. I’m getting exactly the same result as you, so this is deterministic. And what’s curious though, is that this problem is only with 24 FPS. With 60 FPS I’m still getting equal real 60 FPS.
Hmm, I think this requires a deeper look by the developers. Maybe there’s an issue in the algorithm that handles the pacing of the animation playback.
EDIT: To me this must be a bug. Testing the animation on a 32 by 32 pixels canvas the behavior is exactly the same. For every speed, of 1 FPS up, for certain values the resulting FPS is incorrect. For example, frame rate 7 FPS => 6.4 real FPS.
I did some testing with a 1600x900 animation. On 5.2.1 Krita is reporting framerates of:
7 → 6.7
24 → 23.6
30 → 31.7 (?)
48 → 51.2 (??)
60 → 60.7
If I scale the image to 3200x1600, 48 and 60 suffer, the others are the same:
48 → 42~45 (frames are being dropped)
60 → 48~51 (frames are being dropped)
But only if the image is zoomed in (as it is after scaling.) Zooming out, it’s fine again. The problem is only if ‘Use region of interest’ is checked under the Animation Cache settings.
For reference, my Animation Cache settings are (should be default, I hadn’t changed them):
Cache Storage Backend : On-disk
Cache Generation Options:
Limit cached frame size: 2500px
Use region of interest: 25%
Enable background cache generation
I’m not sure if my testing is helpful. But, there could be a lot of factors that go into any framerate issues.
I tested a few Krita builds, and I can confirm that Krita 5.1.5 did not have this bug. If you don’t need other 5.2.1 features, you could try switching back to 5.1.5 until this is fixed. You can still get the binaries from this post:
The older version doesn’t show the real FPS tooltip, but I have measured it manually, and the playback is correct.
AFAICT, the bug got introduced with 5.2.0 release. The actual playback is indeed 21.5 instead of 24 FPS, which is a significant error.
macOS. For what it’s worth, I got similar numbers in a Linux VM (except that I couldn’t really get above 42 fps, even with making the image smaller and zooming out to make it smaller in the viewport (makes a big difference), because of the poor performance in the VM).
If you can get a higher framerate without drops just by increasing the speed or FPS, the 21 fps wouldn’t be a performance issue. More like it’s just not syncing closely enough to the target FPS for whatever reason (similar to my 48->51 result that’s also off by 3).
If it was introduced in 5.2, that’s not surprising given the major changes to animation in that version.
If you attach an audio file to your animation, it should play at the correct FPS. I recommend attaching silence, and in my testing a WAV file worked better. MP3 gave me weird framerate (another bug?).
It doesn’t seem to give any visual feedback in the UI once you import it, but it should play in the background when you start the animation. (I mean, you could try a normal MP3 music file first if you want).
Explanation:
I found that the FPS bug only happens with the Qt playback engine, which is used by default. When an audio track is used in an animation, Krita will switch to Media Lovin’ Toolkit, which is working correctly. I still haven’t debugged what the actual problem is.
Ah, that’s interesting. I did wonder a bit about whether audio was synchronized properly.
With audio, I’m getting somewhere around:
24 → 24.4
30 → 30.4
48 → 49.4
60 → 61.4
(Though I’m now having some framedrops at 48 and 60.)
You could also attach an audio file and then remove it, Krita will continue using MLT after that (at least, until you restart). I’m not sure whether the fallback to using the Qt engine when audio is not present is intended or not.
