On Fri, Jul 9, 2010 at 5:22 PM, Ryan May <rma...@gmail.com> wrote: > I've been "hard" at work over the last couple of months putting > together a set of classes that simplifies the creation of animations > in matplotlib. This started when I resurrected some old code for
Very nice -- people are going to really like this. I've had several requests personally to add something like this so thanks for doing it :-) Some rapid fire comments, in no particular order * on recent ubuntu linux with gtkagg, dynamic_image has a "one pixel" bug on the right side if blit=True. I suspect this has nothing to do with your package and everything to do with gtkagg blitting code having an off-by-one error somewhere. I added this to the tracker: https://sourceforge.net/tracker/?func=detail&aid=3027636&group_id=80706&atid=560720 * this is completely un-thought out, but could we define a subclass of TimedAnimation to work like an iterator so users could do the natural thing : line, = ax.plot(something) for frame in SomeTimedAnimation(fig, blit=True): line.set_data(mydata) frame.update() or something along those lines.... * when you integrate this into trunk, I would like to see widgets.py upgraded to use it. This is not a requirement and I would be happy to help with it, but it is a good way to push on the new API and expand the test cases. * I am happy to see this pushed into trunk at any time. I would not push it into the branch, but we can do a 1.1 trunk release as soon as we are ready (release early, release often). Putting it in the trunk will facilitate testing and other developer contributions. But if you'd rather leave it in github for a while, I have no problem with that either. * you hardcode the artist visible state True/False in ArtistAnimation, which overrides any settings the users may be trying to control. Not sure if this is a problem, but it's something to think about. When you set False in ArtistAnimation._init_draw, should you first store the current state so you can restore the userland settings? You comment that maybe you should be integrating with the "animated" property. This is essentially what this is for, if animated is set it should not be used in drawing the background. Not sure if this matters since it may be sensible to assume they are handing you control of visibility in ArtistAnimation, just throwing it out there. * in Animation.save, why do you set blit=False? When making movies, shouldn't we also depend on the efficiencies of blit? Or was the idea: blit is buggy so for production movies turn it off cause I'm willing to sacrifice performance for quality? If so, I'd rather try an fix the bugs....or expose blit as a kwarg. * a tutorial for the site docs would be awesome. It's one of the big missing pieces in the docs, so this would be a good time to add it. * when you include animation.py in the trunk, would you write the examples as import matplotlib.animation as animation ani = animation.FuncAnimation(fig, ...) per the style guidelines in the coding guide. * let's preserve the old gui specific examples in a subdir of examples/animation, so people who need bare metal control will still have examples to follow. You can add a README in that dir suggesting the use of the new API unless necessary. Nice work. JDH ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
