On Fri, Jul 9, 2010 at 7:27 PM, John Hunter <jdh2358@...> wrote:
> Some rapid fire comments, in no particular order
> * 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()
That's an interesting thought. The challenge would be notifying
SomeTimedAnimation that it needs to stop. Then again, FuncAnimation
already handles this, so it would likely just be a change in syntax,
albeit a good one.
What strikes me now is how to deal with show(). All the animations are
created, and then start once the figures() are displayed with show().
Any ideas on how to make this play with that? At a fundamental level,
these classes are simplifying creating callbacks within the GUI event
loop. I'm not sure the above example can work with that, but I am
ready/willing to be proven wrong.
> * 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.
Interested, but I'm not sure I see your vision here. But then again
I'm too close and only see this animation framework as useful for
animating whole figures. I'm willing to help, but would have to be
led along the way. I will say I was looking at using widgets to make
play/stop/step buttons but haven't really fleshed that out. Those
might also be better done with actual GUI toolkit buttons.
> * 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.
Github was a learning experience and a quick convenience for doing
revision control before it was trunk ready. (Which is a reason by
itself to switch to git, full development history rather than
completed chunks.) I'll check in
after I square away a couple more things.
> * 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.
I'll have to think about that.
> * 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.
You pretty much hit the nail on the head. To be honest, I don't think
I've actually tested blitting when saving, I just wasn't ready to
trust the blitting code that much. It should definitely at least be a
kwarg, and I'll have to test to see how reliable it is.
> * 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.
Definitely. Besides getting everything working, this is #1.
> * 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.
Didn't realize we had that codified. I probably need to go read that now....
> * 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.
Define "bare metal." Since we have the new timer class, I could
convert the old examples to be backend agnostic without using the
animation framework. Just a thought.
Thanks for the useful feedback,
Ryan
--
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
|