Bug summary

CallingAnimation.save on an animation currently being displayed can create a race condition.

Code for reproduction

# At an IPython shell -- here we just reuse an example, but you can# pretend we created our own animation.plt.ion()%run .../matplotlib/galleries/examples/animation/animate_decay.py# Oh, I like it, let's save it.ani.save("/tmp/out.gif")

Actual outcome

The running animation freezes while the save() loop runs (that's more or less OK and unavoidable if we don't want to run save() in a separate thread, which we probably don't want),and after the save() finishes the animation continues, but with intermediate frames being "skipped". In the specific case of animate_decay, some (t, y) pairs seem to disappear and instead the "before" and "after" parts of the sinusoid are connected by a straight line.

Expected outcome

No race condition between the save() and the display timer loop.

Additional information

Admittedly this could be considered a "we're thread-unsafe" wontfix, but on the other hand the end user isn't actually managing any thread themselves explicitly. We could perhaps either explicitly freeze the running animation (to prevent skips of updates) during the save, or even just explicitly error out when trying to save a running animation.

Operating system

macos

Matplotlib Version

3.8

Matplotlib Backend

qtagg

Python version

3.11

Jupyter version

ENOSUCHLIB

Installation

git checkout