Repository navigation
Create a reference example for set_data and friends #19520
Description
Problem
It's tricky to learn that you should use set_data when animating. When i first got into this I was essentially doing:
for t in range(timepoints):
ax.imshow(data[t])which is bad news for performance. I fortunately had someone around to tell me to use set_data but lacking that I think it would have taken me a lot longer to figure out.
However, even after figuring that out it's not all smooth sailing. I was tripped up for quite awhile on how to animate a scatter plot as it uses set_offsets instead of set_data. There can also be other complications see for example #18401.
Suggested Improvement
Include a reference style example in the animation section of the gallery that goes over how to animate all the possible animatable artists (set_data, set_offsets, etc...). Or at least all of the artists that get returned from pyplot functions. Ideally the example would use the artists created from pyplot(or equivalent ax) functions as this is how I imagine most people will create the artists for their animations.
For reference I brought this up on gitter, but gitter just crashed :(
Matplotlib version
- Matplotlib documentation version: any
Activity
timhoffm commentedon Feb 17, 2021
This reference example should also mention the
animatedproperty and blitting. For reference, see #19533.ianhi commentedon Feb 24, 2021
Just to note it would also be great to include the 3d animations as well. As
set_3d_propertiescan be a bit mysterious.bkestelman commentedon Nov 26, 2021
I would add that ideally set_data should be part of the API for the other types of plot (scatter, bar, etc.) as well. It's very confusing that they each have their own method. Moreover, some of the other methods are not as flexible, for example bar's set_heights cannot be used to add data that would create new bars, as far as I know.
I'm curious what the reason is for excluding set_data from the scatter and bar API's. Would it be possible to add it?
tacaswell commentedon Nov 26, 2021
@bkestelman The API is the way it is for "historical reasons" as each of the Artists grew organically. The problem you are identifying actually run much deeper as each Artist stores its data is a slightly different way which makes writing a generic
set_datadifficult. Because each Artist requires a different set of data (with different expected sizes etc) even if we hadset_dataon each artist, the signatures would need to be very different (for example,im.set_extentis as important asset_datafor images and we probably do not want to roll them into one).On the bright side, addressing this problem is one of the goals of the first two grants from CZI (supporting research) and a NASA gant (which will be starting shortly) to implement it. See https://github.com/matplotlib/2020-NASA-ROSES-E7 for more details on what we are planning to do over the next 3 years.
bkestelman commentedon Nov 26, 2021
@tacaswell Thanks for the informative reply and the link. I'll keep an eye on those plans and see if I can contribute anywhere.