Well... I might say "yes", but you did put that word
> "speed" in there 
I'm attaching a modified text.py which uses caching. These changes
alone give be about a 4x increase in frame rate. I reran the profiler
after these changes and there are some other changes that will provide
marginal increases, but this one was the sitting duck. Just drop it
into site-packages/matplotlib/
> You got five frames per second? When you say you improved
> performance "without text" do you mean that you didn't label
> the axes?
My machine is a good bit faster than yours, which accounts for the
difference in frame rates. But you should still get significantly
better performance with the attached file.
> Aside: I see that he calls show() in each iteration, yet
> John says show() should only be called once per script.
> Todd seems to be on top of this, so I'll take his word as
> good. Todd uses a figure manager. I can copy that code,
> but I don't know what I'm doing with it. I don't know what
> a figure manager does.
You don't need to call show. Todd, in fact calls "manager.show()"
which is a different function than
matplotlib.backends.backend_tkagg.show. I would like to unify the
interface so that all backends call canvas.draw, but that is not
possible right now.
> Finally, I'm not sure what he meant by "re-registering the
> handler with each cycle". Does this mean call ....after() ?
He means that it is not enough to call
manager.canvas._tkcanvas.after(100, updatefig) just once in your
script, but that you have to call it for each update you want. By
putting the call in updatefig itself, he insures that the cycle
continues. Just another way of doing
while 1:
updatefig()
sleep(sometime)
> Oh ... one last thing, and maybe this is somehow relevant
> ... Todd's program crashes on exit with message:
>>>> invalid command name "18438384callit"
> while executing "18438384callit" ("after" script)
> ...after which I'm dumped into python (interactive prompt).
I get this too when I try and close the figure while it's running, but
I don't think it's relevant to the problem at hand. I think it just
has to do with inelegantly handling a close.
Here's the new text.py
text.py (13.6 KB)
anim_tk2.py (715 Bytes)