But _save_seq isn't unused. It internally caches "data" for the frames for the case where you're generating the animation live off some generative source--or at least that's the idea.

Is this solving a problem you've run into? The discussion in #8528 indicates that removing this did not solve the issue for the user there.

Thanks for your feedback, @dopplershift

My understanding is that _save_seq is unnecessary, because artists returned by func in FuncAnimation are responsible for holding references to "data" for them to be re-drawn.

Below is a code snippet which exhibits a memory leak at about 1MB/sec before this fix.

#!/usr/bin/env python3
import weakref

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

def main():
    fig, ax = plt.subplots()

    ax.set_xlim([0, 10])
    ax.set_ylim([0, 1])

    np.random.seed(19680801)

    line, = ax.plot([], [])

    def init():
       line.set_data([], [])
       return line,

    def animate(frame):
       line.set_data(frame['x'], frame['y'])
       return line,

    def frames_generator():
       for _ in range(1000):
           x = np.linspace(0, 10, 10000)
           y = np.random.rand(10000)
           yield { 'x': x, 'y': y }

    anim = animation.FuncAnimation(fig, animate, init_func=init,
                                   frames=frames_generator,
                                   save_count=1000)

    plt.show()

if __name__ == '__main__':
    main()

Another way to interpret this bug is that FuncAnimation was holding all frames in memory until it gets destroyed.

Why does FuncAnimation need to hold all frames even if some of them were already drawn?
Could you help to share code snippet showing why _save_seq is necessary if I'm missing something?

If you call save on an animation that was consuming from a generator, add anim.save(...) to your example.

If you change your generator to run through 10k iterations and change save_count to 10 does the memory use plateau?

We probably should change the logic on save_count to treat non-None user input as the gold standard (not the length of the iterable).

There probably should be a flag to disable caching. It is the right thing in many but not all cases.

Thanks for your feedkback, @tacaswell

So, if I understood your comment correctly, Animation is required to support saving its content even after it has already been drawn/shown interactively.
Is this an actual intended/expected behavior?
From user perspective, I think that one would be interested in either drawing it interactively or saving it, not both against the same animation object. I would expect one to create another animation if s/he wants both.

Assuming it's required to support save() even after drawing is complete, I'm afraid to say that this contract forces the implementation of Animation expensive because it needs to keep all frame data.

Having said that, I like your last comment on having a flag to disable caching in FuncAnimation.
If you could help to suggest a good name for the flag, I'm happy to update this PR to respect new flag which wouldn't cache frame data.

So, if I understood your comment correctly, Animation is required to support saving its content even after it has already been drawn/shown interactively.
Is this an actual intended/expected behavior?
From user perspective, I think that one would be interested in either drawing it interactively or saving it, not both against the same animation object. I would expect one to create another animation if s/he wants both.

This is the current behavior (and has been there from when the code came in in 2010 70e401f) so we can not change it with out a deprecation cycle. This is one of the challenges of working on these old, big projects, it is easy to pick any part of the API and say "It would be better if...." but someone is the past thought the current API was a good one and it is likely that there are users depending on that behavior that we can not break without warning (and a good reason). https://xkcd.com/1172/ is real!

Assuming it's required to support save() even after drawing is complete, I'm afraid to say that this contract forces the implementation of Animation expensive because it needs to keep all frame data.

This only gets expensive under some conditions (consuming from a generator that generates and yields objects with a memory footpirnt). itertools.tee has the same problem.

I have personally used this feature when working interactively (make Animation object, watch it on the screen, be happy and do ani.save(...)). Given that you must hold on to the animation object to have it run interactively (or the callbacks get garbage collected), it seems very user hostile to not allow it to also be saved from that object.

Maybe cache_frame_data=True as the kwarg? This should both prevent the caching and cause save to go back to then input.

Could this problem also be solved by passing save_count=0 to FuncAnimation?

Thanks for your detailed/helpful feedback, @tacaswell
I've updated PR to add cache_frame_data=True as kwarg into FuncAnimation.

Coverage is complaining about https://codecov.io/gh/matplotlib/matplotlib/compare/e7719da6cad1d34c7a199833a822f4d2ec076ac8...f8b14c8fc057ef4ed0a67c85df007f5062a4879d/src/lib/matplotlib/tests/test_animation.py?before=lib/matplotlib/tests/test_animation.py#L289 which is a bit odd. Otherwise 👍

Thanks for following up on this @pclove1 !

@tacaswell Thanks for your helpful reviews.
I've added whats_new entry and adopted additional assertion in the test.

Squashed commits and rebased against the latest master head

Travis failure is #13137 and unrelated to the PR.

Thanks, and congratulations on your first contribution to matplotlib. Hope to see you back some time.

Like wise.
It was quite meaningful experience for me to contribute to matplotlib.
Thanks for helpful reviews, all of you 👍