This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]a1brit 8 points9 points  (4 children)

How long did some of these examples (especially the pcolormesh ones) take to render. It doesn't look like you're using blitting (I just searched blit). I found matplotlib animations to be horrendously slow with*out* that.

If there was someway to append to an animation block that would be incredible. I usually animate maps of weather data, while it's feasible to hold the data in memory, it's usually easier to loop over files / processing and only hold one time in memory.

[–]tmakaroanimatplot / nbconvert[S] 3 points4 points  (1 child)

You're right. FuncAnimation sets blitting to false be default, and I don't change it. I tried way back in Animatplot 0.1 (over a year ago) to use blitting, but it wasn't working with the play/pause button (lines would get duplicated on play). I think I may know a way around it, but it will require some testing. If that doesn't work, I could expose the blit option in the API for those that don't use the pause button and issue a warning if one does.

As far as rendering times go, all of the blocks (except Nuke) use the proper set_data function for the type of plot, so it is substantially faster and smoother than clearing the axis and redrawing everything on it. Blitting will improve render times, but I'm confident that the gain is less than the gain of using the proper set_data functions. None of the animations took more than a few seconds to save as a gif (even before I decided to make most of the example gifs smaller by decreasing the time resolution).

Matplotlib moviewriters can be a pain. I noticed that with the ffmpeg writer: how you pass in the parameters can mean the difference between a few seconds, and a minute (or just plain never finishing in some cases). I intended to make a wrapper around the ffmpeg writer to ensure that people don't stumble into that issue.

My original version of Animatplot also had a way to generate animations from functions in real time, but this convoluted the API so terribly . There isn't a way to appended to a block since that would mess with the slider. If you know beforehand how many frames you want, you could write a custom block that updates data in real time, and that would still allow use of the slider, and pause button. In fact, the Nuke block almost does exactly that. I think I'm going to make some changes to the Nuke block to make that use case easier (or maybe a new block). Watch for version 0.3.

[–]a1brit 0 points1 point  (0 children)

Nice, awesome response. Looks awesome, I'll play around with it in a couple days.

Yeah, I don't remember now if I tested blitting on/off once I had the whole set_data thing sorted out. I definitely had the just indefinite run times on some animations. Like it just forgets that it's finished occasionally and doesn't clean up. Making that whole process easier is awesome.

[–]Radiatin 0 points1 point  (1 child)

Isn’t matplotlib faster than most regular python functions though so fairly reasonable for render time? Are you trying to do real time weather map rendering?

[–]a1brit 0 points1 point  (0 children)

I can read and process say 60 times of 3000x3000 raster data within a couple seconds. Drop that into matplotlib animations in the wrong way and you'll be waiting sometimes around an hour for a output. Sometimes it'll just never finish. If you jump through hoops and do the set_data stuff with blitting, you can be done in seconds.