Here's a few thoughts on the interface.

I like the interface of the example as it is now, because it is about as easy to grasp what is going on as can be. Indeed, I would replace the canvas argument to __init__ with a figure argument (and also store self.figure instead of self.canvas). Other than that, maybe update should get a different name (redraw?).

Our internal code replicated part of the interface of the artist that we were using so that you could treat it as an artist and the right thing would happen on, say, set_data. I don't think this interface is general enough, so I would not go that way. I briefly considered not marking the animated artists as animated, but instead set their stale_callback to do the right thing. This would be very ergonomic, but is limited to updates in a single artist for each redraw (also the callback may be called multiple times for each update, e.g. set_xdata followed by set_ydata). That too does not appear general enough to me to support from the library.

Lastly, an attractive interface could be something very similar to animation.ArtistAnimation, but without an interval or repeat. The artists would then be taken from a generator instead of from a list. In principle, the same artists can be reused for each yield, modifying their data each time. The downside is that this favors a pull architecture more than a push architecture, so some shoehorning might be needed for my use case.

An example of use of blitting in hyperspy, that works fairly for many years now - there were a few issues/hacks, but the situation is improving! :) The hyperspy BlittedFigure supports backends with/without blitting for convenience.

Adding the BlitManager to the matplotlib API would been very useful to support third party library using blitting but also for matplotlib to improve/optimise blitting, fix bug, etc. I would be very interested to help with this, even if I need to prioritise other developments!