Issue 1:
Bug report

Bug summary

The following code for an animated visualization stopped working after an upgrade from matplotlib 3.2.2 to 3.3.2.

Code for reproduction

Below is a minimum code for reproducible problem.

import numpy as np
import matplotlib.pyplot as plt
from matplotlib import animation

def create_animated_plot(xs, niter, xlim =(-1.5, 1.5), ylim = [-3, 3]):

line_coords = np.vstack(( np.array([-1,1]), np.array([0,0]) ))

boxData = [np.array([np.zeros(niter), xs])]

fig, ax1 = plt.subplots(1,1)
line, = ax1.plot([], [], lw=2)
ax1.set_ylabel('position')
ax1.set_ylim(ylim)
ax1.set_xlim(xlim)

lines = [ax1.plot([],[],lw=2,color="black")[0]]

def init():
lines[0].set_data([],[])
return lines

def animate(i):
xs = [boxData[0][0, i]]
ys = [boxData[0][1, i]]

lines[0].set_data(line_coords[0,:]+xs[0], line_coords[1,:]+ys[0])
return lines

anim = animation.FuncAnimation(fig, animate, init_func=init,
frames=niter, interval=10, blit=True)
#writer = animation.PillowWriter(fps=25)
#anim.save('animation.gif', writer=writer)

niter = 1001
t = np.linspace(0,10,niter)

create_animated_plot(xs =np.sin(t), niter=niter)
plt.show()

Actual outcome

The actual outcome of the code is the following figure. I.e. an empty plot with all xlabels but there is no plot of the line.

Additionally, something that might help with the debugging, is that if the last two lines in the create_animated_plot() are uncommented,

#writer = animation.PillowWriter(fps=25)
#anim.save('animation.gif', writer=writer)

the resulting gif works as expected (see below).

Expected outcome

The code at the end of the post moves a line up and down in the y direction. It does that successfully with matplotlib 3.2.2, but not with 3.3.2. This is reproducible in different settings.

This code was tested on the following setups (C1, C2, C3 are different computers) with the same results:

C1: A desktop with Asrock Z370 P4, Nvidia 1050 Ti, i5-8600K.

Tested with:

Python: 3.8.3, matplotlib: 3.2.2 OK

Python: 3.8.3, matplotlib: 3.3.2 (problematic)

C2: An Acer Spin 5 SP513-52N laptop.

Tested with:

Python: 3.8.3, matplotlib: 3.2.2 OK

Python: 3.8.3, matplotlib: 3.3.2 (problematic)

C3

Tested with:

Win 10, Python: 3.8.3, matplotlib: 3.3.2 (problematic)

Ubuntu 20.04, Python: 3.8.3, matplotlib: 3.1.2 OK

Ubuntu 20.04, Python: 3.8.3, updated to matplotlib: 3.3.2 (problematic)

In all cases, when I upgraded the problem appeared, and when I downgraded the problem disappeared.

Matplotlib version

Operating system: Win10, Ubuntu 20.04

Matplotlib version: 3.3.2

Matplotlib backend (print(matplotlib.get_backend())): Qt5Agg

Python version: 3.8.3 (also tested in 3.7.6)

Jupyter version (if applicable):

Other libraries:

In machine C1, and C2 I installed through conda.

Issue 2:
Bug report

Bug summary

Animations need to be held in a reference so that they are not gc'ed. I have argued against that behavior in #16221, but as long as we keep it, we could at least add an internal flag tracking whether the animation has been started (I have not checked whether it would be best for this to go in _start or _init_draw or elsewhere), and emit a warning in __del__ if the animation is gc'ed without ever being started, to help confused users (https://discourse.matplotlib.org/t/could-animation-be-triggered-only-when-an-onclick-event-in-silder/21534/2). (Unless someone can think of a reason to instantiate an animation and not start it... and even then we could add a flag i_really_meant_for_this_to_be_perhaps_gced_without_ever_running=True, but let's not get ahead of ourselves.)

Code for reproduction

N/A

Matplotlib version

Operating system:

Matplotlib version: master

Matplotlib backend (print(matplotlib.get_backend())):

Python version:

Jupyter version (if applicable):

Other libraries: