Re: [matplotlib-devel] New Animation Class

[John H. <jd...@gm...>]

On Fri, Jul 9, 2010 at 5:22 PM, Ryan May <rm...@gm...> 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