Hashing stability for transient objects in manim 0.20.1

[pjfo]

Overview: What does this pull request change?

It adds a new class variable to the Memoizer class to enable the class to keep objects alive during the serialisation process for calculating hashes, and thus ensures that certain transient objects don't expire mid serialisation and result in unnecessary re-renders of parts of scenes that have not changed.

It also adds two tests both of which assert the fixed behaviour:

• against a patched manim they pass deterministically (ie the memoizer keeps every recorded object alive, so no address can be reused within a pass)
• against stock ManimCE 0.20.1 they fail, reproducing the bug: CPython's free lists hand a dead recorded object's address to the next same-shaped allocation, so the fresh object is falsely reported as already processed and collapses to the "AP" placeholder.

Motivation and Explanation: Why and how do your changes improve the library?

In the Memoizer class, there is a bug relating to the caching. In particular transient objects created during serialisation (eg the closure variable dict built for every updater or rate function) are freed mid-pass, and when a later allocation reuses one of those addresses the fresh object is incorrectly collapsed to the "already processed" placeholder. This results in the play hash depending on a race, meaning an identical scene can produce different partial-movie-file hashes from run to run, resulting in unnecessary re-renders of already cached partials.

In some of my scenes I was seeing 42/49 partial's being rerendered even though that scene did not change (it was being included in the render pass because I'm compiling a video and my render script attempts to rerender every scene, as it is not aware of which scene I have changed when it is called). After fixing this in my local copy with a patch file, I got no erroneous re-renders of the partials in this scene.

Links to added or changed documentation pages

This is expected:
manim.utils.hashing source

Unexpected (likely due to commits to main after 0.20.1):
These two I'm surprised by given I didn't change anything that would touch these:
Camera
invert_image

Further Information and Comments

Reviewer Checklist

• The PR title is descriptive enough for the changelog, and the PR is labeled correctly
• If applicable: newly added non-private functions and classes have a docstring including a short summary and a PARAMETERS section
• If applicable: newly added functions and classes are tested