Exercises — Animation — FuncAnimation

The update function update runs once per frame. With frames=200 it runs 200 times in one pass (frames numbered 0 to 199). Why: FuncAnimation owns the timer; every timer tick = one update(frame) call = one redraw.

$\text{FPS}=\frac{1000\text{ms/s}}{40\text{ms/frame}}=25\text{FPS}$ Why the division: each frame costs interval milliseconds, and there are 1000 ms in a second, so you fit 1000/40 frames into one second.

An iterable of the changed artists, e.g. return line, (a 1-tuple). Why: blitting only redraws exactly the artists you hand back; it must be told what changed.

$T=N\cdot \text{interval}=150\times 20\text{ms}=3000\text{ms}=3\text{s}$ Why: time-per-frame × number-of-frames = total wall-clock time for one pass.

Invert the FPS formula: $\text{interval}=\frac{1000}{\text{FPS}}=\frac{1000}{30}\approx 33.33\text{ms}$ You must pass an integer, so use interval=33. That gives $1000/33\approx 30.3$ FPS — close, but not exact. (For exact 30 FPS when saving, pass fps=30 to save, which ignores interval.)

def update(i):
    dot.set_data([x[i]], [np.sin(x[i])])   # lists, because set_data wants sequences
    return dot,

Why the brackets [x[i]]: set_data expects sequences (arrays/lists) for both x and y, even for a single point. A bare scalar x[i] can raise or misbehave. Why return dot,: the trailing comma makes a 1-tuple — the iterable blit needs.

Cause: FuncAnimation(...) is not stored in a variable. When make() returns, Python has no live reference to the animation object, so it is garbage-collected; its timer dies and the frames stop. Fix: keep a reference alive:

anim = FuncAnimation(fig, update, frames=100, interval=30, blit=True)
plt.show()   # anim stays alive for the whole show()

Why a reference matters: the timer that drives frames lives inside the animation object. No object → no timer → no frames.

Cause: ax.plot adds a new Line2D artist every frame. Old lines never get removed → the axes accumulates hundreds of lines (memory grows), and blit can't tell what actually "changed." Fix: create the line once outside update, then only mutate it:

line, = ax.plot([], [])          # created ONCE
def update(frame):
    line.set_data(x, np.sin(x - 0.1*frame))   # mutate, don't add
    return line,

Why this is the whole point of blitting: cost drops from "redraw every artist ever added" to "redraw the one moving line."

Cause: with blit=True, matplotlib redraws exactly what you return. You returned only line,, so the dot is never re-blitted — it looks stuck. Fix: return all changed artists:

return line, dot

Why: blit's contract is "I will repaint precisely this iterable." Forget an artist and it will not update on screen.

def frame_gen():
    t = 0.0
    while t < 6.28:
        yield t
        t += 0.04
 
def update(t):
    line.set_data(x, np.sin(x - t))
    return line,
 
anim = FuncAnimation(fig, update, frames=frame_gen,
                     init_func=init, interval=20, blit=True,
                     save_count=157)
anim.save("wave.mp4", fps=50)

How many frames? Count the values $0,0.04,0.08,\dots$ that stay below $6.28$. The number of steps is $\lceil \frac{6.28}{0.04}\rceil =\lceil 157\rceil =157\text{frames}.$ Since $157\times 0.04=6.28$ is not strictly less than $6.28$, the last emitted value is at step $156$ (value $6.24$), giving indices $\mathrm{0..156}$ = 157 frames. Why save_count: a generator has unknown length; when saving, matplotlib must know how many frames to pull. save_count caps it — set it to the true frame count so nothing is dropped or padded.

Live FPS is $1000/25=40$. To match speed, save with ==fps=40==. $\text{live FPS}=\frac{1000}{\text{interval}}=\frac{1000}{25}=40$ If you save with fps=50 instead: the same number of frames now plays $50$ per second instead of $40$, so the video is $50/40=1.25\times$ faster (shorter duration). Why they can differ: interval only controls the live GUI timer; save(fps=...) re-spaces the same frames at $1/\text{fps}$ seconds each, ignoring interval entirely.

(a) One live pass: $T_{\text{live}}=N\cdot \text{interval}=90\times 40\text{ms}=3600\text{ms}=3.6\text{s}$ (b) No. repeat only loops the live preview. Saving captures each frame once (up to save_count), so the file contains one pass regardless of repeat. (c) Saved video: $T_{\text{save}}=\frac{N}{\text{fps}}=\frac{90}{30}=3\text{s}$ Why (a) ≠ (c): live spacing is $40$ ms/frame (⇒ 25 FPS effective), but the file is spaced at $1/30$ s/frame. Same 90 frames, different playback rate ⇒ different duration.

(a) If part of the static scene changes (e.g. you update the axes title or tick labels or the axis limits inside update), blit won't repaint it: blit caches the background bitmap once and only re-blits the returned artists. The title/ticks live in the cached background, so they appear frozen or leave smears. (Fix: don't animate background elements under blit, or return them too / disable blit.) (b) init_func draws the clean "frame-before-0" state. Under blit, this is the frame matplotlib captures as the reusable background bitmap. Omit it and the first cached background may include leftover/empty artist state, causing ghosting or a blank first frame. It also guarantees a well-defined starting picture for repeat. Why this is the deep rule: blit's speed comes from freezing the background. Anything you want to move must (i) be a returned artist and (ii) live above that frozen background.

Last frame is i = 50 (since range(0,51) = 0..50). Then x[:50] takes indices 0..49 → 50 points, largest x = x[49]. With 51 points evenly on $[0,1]$: spacing $=1/50=0.02$, so $x[49]=49\times 0.02=\mathrm{0.98.}$ Why not $x[50]=1.0$: x[:i] with i=50 is a half-open slice — it excludes index 50. The final point $1.0$ never appears unless you also allow i=51 (or slice x[:i+1]).