Why the current animation system isn't good enough.

[AntonBallmaier]

Starting to learn Manim is hard. We all know that. The way I see it a lot of that initial struggle could be removed with a few core adjustments to how the animation API is structured. Let me present my ideas on how to fix common issues:

add_updater

• This method should not exclusively exist for Mobject, but also for Scenes. Sometimes updaters concerning the whole scene are added to mobjects just because you have to.
• Additional parameter use_time_difference which is True by default. In some situations it is much more practical to get the total time since adding the updater instead of the time difference since last calling it. I would also like it if use_time_difference would be set to True if the parameter of the given function is named dt but to False if it was named t.

Scene.play

As already mentioned in #1267 we should enable starting new animations using Scene.play() while others are running. Let me explain in detail how that could work:

• Animations are playable in two distinct ways: synchronous or asynchronous (new keyword async:bool). By default (and the way it is currently implemented) animations should be played synchronously, meaning the execution of the code in the Scene.construct method only continues once the animation is over. Playing an animation asynchronously would add the Animation to a list of currently active animations and return immediately to the Scene.construct execution. Only once a different synchonous animation call (or call to Scene.wait) is executed will the async animation be played in parallel.
• If scene.play is called while the scene is currently playing an animation synchronously (for example from an updater), it plays asynchronously by default. If async is set to False explicitly, the new animation should block the current synchonous animation from continuing and play to finish before the first sync animations is continued.
• A new method Scene.finish_animations should be added. This should simply wait until all animation (async and sync) have finished.

Mainly the changes to Scene.play would reduce the complexity of many scenes immensely. You would no longer have to plan more complex animations ahead of time using wired nested AnimationGroups.

Open problems

I have basically no clue how this could be implemented - I haven't even had a look into how the current implementation of play works. I think async animations could be implemented as self removing updaters. However, there are a few things that I believe could be problematic when trying to implement this:

• How should partial movie scenes be structured?
• How does hashing handle this?

Please let me know what you think about these ideas. I strongly believe enhancing the animation api would greatly improve manims learning curve for beginners as well as the productivity of experienced users.

[eulertour]

All of the updater changes sound like good improvements to me, but the animation changes sound like a lot of extra complexity for a pretty niche use case. When would an async animation be preferable over a regular animation or updater?

[AntonBallmaier]

Some use-cases I have encountered:

• A bit more complex version of the example in Starting Animations using Scene.play while others are running #1267
• 3b1b struggling with this in quite a few occasions like in his windmill video (https://youtu.be/M64HUIJFTZM?t=185). Notice how the Flash animations get cut of since creating the animation correctly using an AnimationGroup would be to complex.
• Many cases of updaters triggering indication animations, like indicating a counter whenever it changes...

[AntonBallmaier]

...but the animation changes sound like a lot of extra complexity...

I do agree however that allowing to start blocking sync animations while another animation is running synchronously might not be necessary.

[eulertour]

I think that's a reasonable use case. It'd probably be simpler if attempting to call Scene.play() without the async flag while an animation is running was just an error.

That said making it work properly would require a pretty fundamental change to manim's internals so it will take some effort an planning.

[AntonBallmaier]

That's basically why this post isn't an issue :)

[Darylgolden]

I think async animations is pretty necessary too, the current method hacking through LaggedStart and LaggedStartMap is not ideal at all.

[AntonBallmaier]

I will be starting to work on these features today if there are no further ideas on what should be added related to this change 🙂

[markromanmiller]

you are an unstoppable force in this repository. good luck and godspeed :)

[huguesdevimeux]

So uuh just to add my little thought about it :
I think that the idea behind the async thing is the way to go. However,

If scene.play is called while the scene is currently playing an animation synchronously (for example from an updater), it plays asynchronously by default. If async is set to False explicitly, the new animation should block the current synchonous animation from continuing and play to finish before the first sync animations is continued.

This, I .. don't really see the point. Why would an animation need to block everything ? I don't see any good reason to want this.
For me, async should be automatically set to true when the play is 'inner' and the user shouldn't have a control on it.

By the way, there is no issue with both partial movie files and hashing if you chose to make a clear distinction between outer plays and "inner" plays call. If you don't, it won't work, since at each play call a FFmpeg pipe is opened, a file is written etc. it wouldn't be a good thing IMO to open several pipes in parallel. (for hashing, it shouldn't be a problem though)

[AntonBallmaier]

This, I .. don't really see the point. Why would an animation need to block everything ? I don't see any good reason to want this.
For me, async should be automatically set to true when the play is 'inner' and the user shouldn't have a control on it.

Yeah, thats what am going for :)

[MrDiver]

Was there any attempt made ?

[behackl]

#1520, #1528