On Sep 20, 2010, at 9:58 PM, Ryan May wrote:
> On Mon, Sep 20, 2010 at 8:14 PM, Brian Blais <bbl...@bryant.edu> wrote:
>> sure, but that take more effort, and I don't really care about a slow down,
>> because most of my time is spent in the busy loop.
> It might be more effort, but what you're doing now plays havoc with
> GUI event loops. Now, granted, until EPD upgrades to Matplotlib 1.0.0
> this won't work for you (unless you're willing to install your own),
> but this is how IMHO is best to approach this problem:
>
...
> def busy_loop():
> for i in range(1000):
> r = np.random.rand(100,100)
> return r
>
> def update_plot():
> update_plot.count += 1
> r = busy_loop()
> plt.clf()
> plt.imshow(r, interpolation='nearest', cmap=plt.get_cmap('gray'))
> plt.draw()
> dot()
> # Automatically stops after 10
> return update_plot.count < 10
> update_plot.count = 0
>
> fig = plt.figure()
> # Creates a new timer that fires every 250 ms
> timer = fig.canvas.new_timer(interval=250)
> timer.add_callback(update_plot)
> timer.start()
> plt.show()
>
> This, to me, isn't any more complex than your original (the most
> complex part comes from getting it to stop after a fixed number of
> iterations).
actually, I think the workflow that I use doesn't lend itself well to this.
usually what I do is write code in the local space, in a if
__name__=="__main__" block, so that after things run I can easily inspect
variables, test the results, rerun, etc... It's only after things work that I
box it into a nice function that can be called with an event callback. this is
one of the reasons I use python, so that I can easily interact with my data.
why does the way I wrote things play havoc with GUI event loops? it shouldn't
care, or at worst the GUI parts of the window (menus, buttons) should be
unresponsive when the plots are drawn but the plots should at least be drawn!
> The benefit is that the timed updates integrate into the
> GUI event loop and don't fight it. The other benefit is that this
> works with any of the interactive backends and you don't end up
> debugging weird draw problems. Even when I've gotten your style of
> animation to work in the past, I've still had problems where resizing
> the figure, etc. don't work.
perhaps I can write things this way, and have the function inject into
locals(), just to make it easier to debug the results, but that seems to me to
be a bit of a hack. I'm not really interested in an animation, as much as
easily visualizing my data every so often.
when people come from using matlab, and then hit odd draw problems like this,
it is disconcerting.
bb
--
Brian Blais
bbl...@bryant.edu
http://web.bryant.edu/~bblais
http://bblais.blogspot.com/
------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
