Bug 458862

Hi Maarten,

Thanks for taking the time to file bugs/wishlist requests. There's quite a few issues to tackle here, so I'll probably take the time to split this up into multiple bug reports once I can confirm them as that's typically how we do things (since 1 post with many issues within makes it hard to track actual progress). If you could, in the future, post 1 issue or wish per post, that would be great.

Before I do that though, I have a few questions or observations...

> * Layers aren't synchronized while playing
> When playing an animation consisting multiple layers with keyframes these layers don't synchronise but seem to be individual instances playing individually at a different speed/refresh rate. This is obviously not what we want when creating frame by frame animations and makes the preview of animations unreliable.

This doesn't sound right, it shouldn't be possible as the image itself is the only keeper of time (a layer and another layer cannot have different "current times", for example.) Can you provide an example project for this? Are you positive you haven't misaligned two keyframe positions in the timeline docker?

> * Please keep start and end frames fixed!!!!
> When working with animations it's pretty frustrating to constantly see the start and end frames of the timeline loop change 'automatically'. I guess this got automatically changed when adding frames before the current start frame or after the end frame, but we never want these start and end framenumbers to loop to automatically change.

For the record, this is configurable as it's something we know users have differing opinions on. You can turn this off in unchecking `Settings > Configure Krita... > General > Miscellaneous  > Adapt Playback Range to Keyframes` I think an argument could be made that this setting should be made easier to find. Some users do actually prefer to have some adaptability to playback range (particularly, new users who just want a frame to render at a certain time, for instance.)


> * Timeline is skipping keyframes
> While playing often keyframes are skipped while playing. They aren't only skipped in the display of the timeline view, but also in the viewport the frame is not shown. This makes previewing animations unreliable.

This is also a setting, though more cleanly presented in the GUI as the "drop frames" button. Generally speaking, animators like to keep frame time consistency so stopping when the computer slows down is not ideal when it comes animation. So, for example, frame 20 would either always occurs at 0.8333 seconds or is skipped when it misses that deadline in favor of the next immediate frame (when the computer is next available.) You can disable this by unchecking the `drop frames` button on the animation title bar.

Hi Eoin,

No worries. I understand that it's best to split items and I normally do, but this time it were a little bit too many for the time I had so, as an exception, posted them in one thread. Understand why you ask and I Will mention other things per item from now on.

**SYNCHRONISATION**

>> This doesn't sound right, it shouldn't be possible as the image itself is the only keeper of time (a layer and another layer cannot have different "current times", for example.) Can you provide an example project for this? Are you positive you haven't misaligned two keyframe positions in the timeline docker?

I woult think the same, but it really happened. Mostly frames are synchronized, but sometimes they're not. Look in the video I created during the making of an animation. At around 7 seconds of the video below on youtube (when the drawn body comes in), the beak is not playing synchronized with the body. While this WAS working when just manually stepping to the next frame. So frames are show differently when playing an animation compared to when stepping through the frames one by one. You can clearly see in the video that later on suddenly the exact same beak (unchanged) is (somewhat?) synchronized again with the body.

https://youtu.be/iuyUtVQAj5E?t=7


**FIXED START/END FRAMES**

>> For the record, this is configurable as it's something we know users have differing opinions on. You can turn this off in unchecking `Settings > Configure Krita... > General > Miscellaneous  > Adapt Playback Range to Keyframes` I think an argument could be made that this setting should be made easier to find. Some users do actually prefer to have some adaptability to playback range (particularly, new users who just want a frame to render at a certain time, for instance.)

Thanks! That was exactly what I was looking for, but couldn't find. That did the trick.

> This is also a setting, though more cleanly presented in the GUI as the "drop frames" button. Generally speaking, animators like to keep frame time consistency so stopping when the computer slows down is not ideal when it comes animation. So, for example, frame 20 would either always occurs at 0.8333 seconds or is skipped when it misses that deadline in favor of the next immediate frame (when the computer is next available.) You can disable this by unchecking the `drop frames` button on the animation title bar.

Yeah, I found that one after posting the issue here. Sorry for not mentioning this. BTW It's practically impossible to see if this button is selected (at least when in dark mode). It could use way better contrast at least in that theme as you just cannot notice it's on or off.

For the rest basically the 'cycle onion skin' option was the one I really missed, besides being able to copy and paste parts of one keyframe to another. Both are overly complicated and time consuming now and I missed them a lot.


But especially for free software you guys did a very great job and I can't complain. Also great that you react to this thread so soon already! There are always things that can be better, but I love the brushes and just love the overal feeling of using Krita. Keep up the great work!

I spent some time retesting synchronization across a few of my test files, but I wasn't able to reproduce any issue.

Is this still something that you're seeing regularly, Maarten? 
If so, providing a test file or known steps to reproduce the problem might help us sort it out.

Because I can't reproduce it myself right now I'll be setting this one to "WORKS FOR ME" status, but if this is something you're able to help us reproduce then we'll re-open the bug report.

>But especially for free software you guys did a very great job and I can't complain. Also great that you react to this thread so soon already! >There are always things that can be better, but I love the brushes and just love the overal feeling of using Krita. Keep up the great work!

Thanks for the kind words, and of course for the bug report. :)