Repository navigation
Migrate BlitManager from docs to library #22183
Description
@tacaswell wrote:
Had some thoughts about hardening BlitManager a bit more and putting into the library, but was not sure where to put it and starting in a tutorial seems like a lower-stakes place to start.
That BlitManager class looks pretty useful for 'live' plots that are not timed (e.g. we want to plot at the rate that data becomes available). Maybe the class could be put in matplotlib.animation?
Originally posted by @joukewitteveen in #10187 (comment)
BlitManager is a class that was written for pedagogical and documentation reasons in #10187. When I wrote it I had an idea that it would be generally useful, but was not sure (and did not put in the work to harden / test the code). We now have a user who asking for it so this seems like a good time to re-consider!
The use case that @joukewitteveen has is being on the receive side of a push notification that there is new data, but I think this would make sense anytime that a user wants more control over the timing of the animation (you could also do this with clever use of concurrency + generators but that gets complicated fast).
The work that needs to be done:
- review the API (it should take a figure not a canvas I think)
- add tests
- think through event loop integration (do we want to call canvas.flush_events?)
- make sure it works on all backends that support blitting (I think the OSX related issues are now fixed, but would be good to check).
- write a tutorial on using it / adapt the existing section to be about it.
We may want to do this in the main repo, but I could also see this fitting in mpl-gui ( https://github.com/tacaswell/mpl-gui) at least to start
Activity
joukewitteveen commented on Jan 11, 2022
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.
ericpre commented on Jan 11, 2022
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!
github-actions commented on Mar 16, 2026
This issue has been marked "inactive" because it has been 365 days since the last comment. If this issue is still present in recent Matplotlib releases, or the feature request is still wanted, please leave a comment and this label will be removed. If there are no updates in another 30 days, this issue will be automatically closed, but you are free to re-open or create a new issue if needed. We value issue reports, and this procedure is meant to help us resurface and prioritize issues that have not been addressed yet, not make them disappear. Thanks for your help!
timhoffm commented on Mar 16, 2026
Explicit blitting might be superseeded by a layer drawing model, see #30953, #30515 (comment).
I would not invest any effort into this issue right now. The question is whether we put it on hold or want to close.