Multithreaded Rendering?

[IAmAThousandTrees]

I'm not too familiar with the internals of Manim or how python does threading, or even python if I'm being honest (I'm really only learning python in order to use Manim), so there might be something preventing this from being viable that I cannot see... but it seems to me that there's a big missed opportunity in not threading the rendering process.

I'm making video's that have hundreds of animations in a 10-minute run-time and it takes upwards of 30 minutes to even re-render (with 90% of clips only being hashed) after a small edit.

My thought is this: wouldn't the hashing/clip-re-use process provide an ideal junction point for threading the process? everything required to uniquely specify an animation is gathered together for the process of hashing it. If all of that gets packaged up and handed to a worker thread as its task (deep object copy?) - to hash and then render if required - then all that is required is to simulate the results of the animation, which i presume is done anyway if the hash finds the render unnecessary, and continue with running the user code in the main thread.

Wait for all the render threads to return the files they've identified/rendered, smoosh them together as usual, done.

It's probably sensible to limit the number of concurrent threads to the N of CPU threads by blocking the main thread waiting on any worker thread return when starting the Nth thread.

The progress reporting might have to be re-written for handling multiple simultaneous renders, but that's not a big issue.

[JasonGrace2282]

I think the developers have had lots of conversations about this - if you have any questions, feel free to ping us on discord :)
Before I go any further, I do just want to note that multithreading would go against the idea of live rendering with OpenGL.

The problem is really in two parts - the current architecture of Manim is insufficient to handle multithreading correctly, and the user has an incredible amount of "power" in what they can do. I'll tackle the second point first, because it's easier to describe.

Take this code for example:

sq = Square()
self.add(sq)
self.play(sq.animate.shift(RIGHT))
self.play(FadeOut(sq))

It's pretty obvious that the way the second animation (FadeOut) looks depends on the state after the first animation. This can (probably) be worked around, by abusing the way animations work. However, there are more complicated examples (typically related to updaters - see TracedPath) where the final state of an object depends on each frame throughout each animation. There's no way to figure out the final state of the object in advance, and so there's no way we can dispatch a worker thread for the next play call without finishing the current play call.

Now, the next thought is to make the user explicitly opt-in to threading their code (maybe checking if updaters exist, or forcing users to mark updaters with an attribute if they are "pure"). Trying to handle this with our current architecture (relevant docs) is an absolute nightmare, and is bound to cause bugs. In order to do this in the least hacky way possible, we would have to rewrite the Scene to use a two pass rendering system, where the first pass runs through the user code and gathers all the actions that need to happen, and the second pass executes them (threading them where possible). As you can imagine, this is a HUGE change that would need to happen.

But now! All hope is not lost! Unlike what it may seem like, the devs are still making huge leaps towards improving Manim. We have a refactor branch where we've rewritten the renderer and Scene by introducing a Manager class to handle all the rendering logistics, which should make it much easier to possibly parallelize certain animations. I wouldn't expect it to be ready for any time before Manim v0.21.0, but if you want to check out the progress, you can always take a look at #3817

[IAmAThousandTrees]

lamdas can be pickled with dill (lol) so maybe not so hard? since 3.6 according to SO:

>> import dill
>> f=dill.loads(dill.dumps(lambda x:x*x))
>> f(5)
25

[IAmAThousandTrees]

also, using multiprocessing.pool and collecting the future results looks useful

[behackl]

IIRC there were some issues with dill that would have required further changes; I can't quite remember details though. Worth a try.

[IAmAThousandTrees]

further research reveals that a fork of multiprocessing that uses dill by default exists, called multiprocess. created and actively maintained to allow distributed processing. I'll give it a try and see what the issues are, although my animations so far don't use updaters so I may not see any issues even if there are some.

[IAmAThousandTrees]

I just want to mention that I am not a reliable person to leave this to. I will probably try, but I am long-term unwell (chronic exhaustion) in a way that for some of the time affects brain function as well, making it impossible to say that I will be able to complete anything. My projects often end up on hold for months, waiting for me to have the energy to get over a bump in the road.

If someone thinks this is a useful thing to try they should take it on rather than waiting for whatever I might produce.

That said, I'm back on it today, after a break yesterday, but this is fair warning.