Closed rjleveque closed 6 years ago
I never liked the approach of writing to file and then loading back to create the animation, but given the existing visclaw infrastructure it seems difficult to avoid. In any case, I don't understand what part of the process is different between using our JSAnimation and the one in matplotlib -- they both use imshow
, right?
I think users will not understand the warning message; perhaps it's better to have it say something like "Warning: in the future, creation of animations will require Matplotlib 2.1 or greater. Please update your matplotlib."
Sorry, I was mixed up about the warning messages -- they actually make a lot of sense as they are.
One thing that isn't very important: I believe jsanimation was incorporated in matplotlib 2.1.0:
Yes, it would be nicer to make the animation directly from a list of fig's rather than png's. This would require some refactoring but probably worth doing eventually.
I can't figure out why to_jshtml
gives different results than the old JSAnimation, maybe I can get @jakevdp to help me out with this at some point.
Various dpi and figure size defaults changed in matplotlib 2.0 that seem to affect how well a png read in as an image gets rendered. Experimenting with figsize and dpi on figures and savefigs, I have not been able to reproduce as nice resolution in animations as we used to see, at least not without increasing the figure sizes substantially to where they often don't fit in the browser window nicely.
One can get something close by doing
import matplotlib as mpl
mpl.style.use('classic')
but it's still not great.
Closing this for now. Additional testing has not helped resolve the issues with the JSAnimation now built into matplotlib, so let's stick with the local version for now.
Addresses #223.
Try to use JSAnimation from mpl if available, if not try to use local JSAnimation.
Leaving the local version in for now for two reasons:
Presumably the second issue can be fixed by improving the resolution of what is displayed by
imshow
. Compare: