SUMMARY Tried to load 250 frames 1080p (1920x1080) of a camera animation (produced in Blender) to test the loading time, showed that the software has taken too long, plus trying out 'Jump back' and 'jump forward' buttons doesn't seem to do ANYTHING. Generating cache stopped at 99% and just hanging in there, must pressed the 'Cancel' to get out. STEPS TO REPRODUCE 1. Use Blender (any version from 2.78 onwards) with 250 frames animation of rotating camera round a cube (this video is possibly can be a tutorial candidate to guide you to perform such an activity: https://www.youtube.com/watch?v=1oD3gSX3ICM), save the animation as PNG images, 250 of them, in one location. 2. Use Blender to load the produced frames using Video Editing workspace and observe how quick all 250 frames can be brought into the software (instantly) 2. Open Krita, with 1920x1080, 300dpi layout, 3. Switch to 'Animation' layout, perform File->Import animation frames and observe how slow all frames are loaded? Remember to press Cancel at the 'Regenerating cache...' dialog when it stops and hangs at 99% 3. Try to select a frame in the middle (off 0) and press 'Jump Back' and 'Jump Forward' buttons and notice the playhead doesn't seem to do anything OBSERVED RESULT - Slow loading of frames (noticed that the video has already been sped up almost double) - 'Jump Back' and 'Jump Forward' buttons doesn't seem to do anything to the position of the playhead EXPECTED RESULT - Loading at LEAST is the same as Blender - 'Jump Back' should move the playhead to the FIRST FRAME (or a number of frames configured somewhere) - 'Jump Forward' should move the playhead to the LAST FRAME (or a number of frames configured somewhere) SOFTWARE/OS VERSIONS macOS: 10.15.7 ADDITIONAL INFORMATION Screencast of testing procedure and the comparison with Blender loading time (https://drive.google.com/file/d/1B_FbDsZneshou7Sqo6_RWTLsTS6U4QKY/view?usp=sharing) Test data: 250 frames in a single zip file: (https://drive.google.com/file/d/1HwPqMAxeOUea6Mfx1Y_omXLUwcuT5iuK/view?usp=sharing)
> EXPECTED RESULT: Loading at LEAST is the same as Blender I'll comment only this part. It will be never possible because the two techniques (Blender way and Krita way) are really different. While what you see (an animation of a camera and cube) might be consistent between both, under the hood it's even not comparable. Blender load many things; but you can simplify it this way: the position of the camera, position of the cube, light, etc... and then Blender playback the receipe and render in real time the animation. While for Krita, the animation is already made and baked as frame in pixels. And it's heavy in information. Heavier than just the position of the camera, the cube, etc... It's 250 canvas of 1920x1080 ( so ~2Million of pixels per frame with each pixels their own color coordinates x 250 time ). That's why this part is technically impossible, I hope you'll better understand now.
What about this idea, load only the first frame, or where ever the playhead is, and only show 1920x1080 * size of pixel, and display it in canvas, because after loading the animation in that's what is shown. Then open (forking) a thread in the background to load other frames in, creating a reduced version for display purposes if you like (automatically, in Blender they called proxies, by default is 25% of the original), so at least allowing user to scrubbing through the video without any visual delays. Just a suggestion for the implementation. If I was doing the coding, that's what I would have done in this situation, to speed up the display.
Im sorry but I cannot reproduce any of this issues. Frames load and playback as they should, remember we are loading the frames for animating, not for editing, so a lot more happens to prepare the pixel data to be composited. Notice that in my case I had no progressbar stuck at 99%. The buttons reported as not working work as expected, they are designed to help an animator to skip from keyframe to keyframe (they can work in 2's, 3's, etc): in your example the background layer had no keyframes, which makes the tool do nothing. krita (75bbbf6912b) SOFTWARE/OS VERSIONS macOS: 12.0.1
I was using nightly build (krita-nightly_d2f29d7.dmg), downloaded on 14/11/2021. After read your comment, I went to download the 'krita-5.0.0-beta2.dmg' (today, 18/11/2021) and was able loading all 250 frames, with little delay (sustainable), I still notice the delay when I started playing 'Cache regeneration..' but no 99% stuck as previous version. Still the 'Skip Back' button moves 1 frame backward, identical to the 'Back' button, and 'Skip Forward' button is functioning exactly like the 'Forward' button. I don't understand why you'd need TWO BUTTONS performing exactly the same function. If I was editing I would JUMP by my mouse to a position where I would like to place my next frame, this must be done by MOUSE POINTER, only when I would like to jump to the beginning should I use 'Skip Back' (or rather misleading name, it looks more like 'First Frame' button) and the other looks more like 'Last Frame' button, honestly.
(In reply to Hoang Duy Tran from comment #4) > I was using nightly build (krita-nightly_d2f29d7.dmg), downloaded on > 14/11/2021. After read your comment, I went to download the > 'krita-5.0.0-beta2.dmg' (today, 18/11/2021) and was able loading all 250 > frames, with little delay (sustainable), I still notice the delay when I > started playing 'Cache regeneration..' but no 99% stuck as previous version. > Still the 'Skip Back' button moves 1 frame backward, identical to the 'Back' > button, and 'Skip Forward' button is functioning exactly like the 'Forward' > button. I don't understand why you'd need TWO BUTTONS performing exactly the > same function. If I was editing I would JUMP by my mouse to a position where > I would like to place my next frame, this must be done by MOUSE POINTER, > only when I would like to jump to the beginning should I use 'Skip Back' (or > rather misleading name, it looks more like 'First Frame' button) and the > other looks more like 'Last Frame' button, honestly. The "skip forward" button will jump to the next available keyframe on the active layer. As such, if a keyframe exists on every available frame (on 1s, in animation talk), both the next/skip forward buttons will appear to do the same thing. As of now, if there are no keyframes on the active layer, nothing happens when you when you hit the skip buttons. We could probably still do something useful in that edge case, but I believe the buttons are working as they should. If things are not working as you expect, it's probably that you have the wrong layer active. Anyway, if this bug is something that can no longer be reproduced, I'm going to close this report for now. Thanks all.
Thank you, I understood the meaning of 'skip' now. Just my two cents, there appears to be a need for first and last keyframe access, can user hold down a modifier key (say Ctrl/Alt etc) when pressing on those 'Skip' to jump to frame 0 or to the last keyframe if 'Forward'
> Just a suggestion for the implementation. If I was doing the coding, that's what I would have done in this situation, to speed up the display. If you have a patch for that, it would be very welcome as a merge request here: https://invent.kde.org/graphics/krita/-/merge_requests . For now, since it's very understandable that Krita takes quite a long time for such a big amount of data to load, (note that it doesn't need to just show it but allow you to edit it - I don't think you can edit pixels for every frame in Blender... though I might be wrong. In any case Blender has much more programmers than us, it's a much bigger project, so it's uderstandable that it's also more performant). ------- Also, a note for the next time: one bug report should be about one issue. Otherwise there are multiple conversations going on about different topics and it's more difficult for a programmer to see what the issue is/are or when to close the report (bug reports are very development-oriented, it's our place to organize work on Krita, so it's important to us to keep it in order). It's completely fine (even strongly encouraged) to create a three bug reports at the same time, if you have three issues to report. Bug reports are more like a register of all issues instead of a forum thread, it's for example very common for a bug report to wait undefined amount of time without any interaction until finally someone gets to work on it and makes another comment or closes the report with a commit hash.