Re: [Matplotlib-users] Re: Dynamic plots with matplotlib and wx on OS X

[Leighton P. <lp...@sc...>]

Hi Matt,=0D=0A=0D=0AOn Thu, 2005-03-24 at 22:48 -0600, Matt Newville wrote:=0D=
=0A> I'm no expert in wxPython or matplotlib, but there are a few=0D=0A> po=
ssible problems with your script:=0D=0A>  - For the timing method, I think =
the issue is simply how fast=20=0D=0A>    you can send Timer events.  You'r=
e doing them every 20ms,=20=0D=0A>    which is pretty fast (I'm willing to =
take the blame for=20=0D=0A>    sending you an example that goes that fast!=
).  If you change =20=0D=0A>    that to 200ms, I'll bet you will see more u=
pdates.=20=0D=0A=0D=0AThe timer was working pretty well on all three system=
s at 20ms intervals=0D=0A- no blame to apportion there! ;)=0D=0A=0D=0A>  - =
The Loop method [...]=0D=0A>  - The Custom Event [...]=0D=0A> For all these=
, I would think that adding=0D=0A>     self.Update()=0D=0A> should help.  =0D=
=0A=0D=0AI added self.Update() to each frame on the update event, and that =
fixed=0D=0Amy problem on OS X. I'm guessing that the wx.Timer events force =
an=0D=0Aupdate=3F=0D=0A=0D=0A> I think you want to avoid the Loop method, a=
s it can block other=0D=0A> widget events. I believe that what you want is =
to replot the=0D=0A> figure when (a) the data has changed and (b) some mini=
mum time=0D=0A> has elapsed since the last drawing.  One approach is to use=
 a=0D=0A> timer to periodically check (this sets the minimun time) for new=0D=
=0A> data, and redraw the plot when there's new data.=0D=0A=0D=0AI'm less b=
othered about the minimum time, though I do like the idea of=0D=0Asetting u=
p a timer in the monitor frame, and polling for a changed state=0D=0Ain the=
 object it's monitoring, and might change part of my design to=0D=0Aimpleme=
nt that in the 'real' code.=0D=0A=0D=0A> Another approach is to trigger on =
changes in the data, possibly=0D=0A> saving the timestamp when a redraw is =
done so as to not draw too=0D=0A> often.  Which method to use probably depe=
nds on how easily it is=0D=0A> to detect and act upon changes to the data. =
=20=0D=0A=0D=0AThis is what I'm doing in the full application (bar the time=
stamp) at=0D=0Athe moment - it's under a 'data-push' model at the moment.=0D=
=0A=0D=0A> Finally, you may also consider putting the data-intensive code i=
n a separate=0D=0A> thread from the GUI.=0D=0A=0D=0AAh, threads...  I'll st=
ick to the self.Update() for now ;)=0D=0A=0D=0A> But I think the main issue=
 is to not try to redraw the plot 50=0D=0A> times per second. ;).=0D=0A=0D=0A=
<grin> My algorithm coding isn't good enough for that to be an issue,=0D=0A=
anyway.  But I think the root of the cross-platform problem might lie=0D=0A=
elsewhere, and the different steps I had to take on each OSs are=0D=0Apuzzl=
ing me.  On Windows I didn't need to add self.Update() calls, as=0D=0Aevery=
thing worked first time.  On Linux, the plot updated without resort=0D=0Ato=
 self.Update(), but the buttons didn't - and adding the self.Update()=0D=0A=
calls only caused the buttons to appear blank, rather than not=0D=0Achange.=
=2E.=20=0D=0A=0D=0AOn OS X, however, adding the self.Update() calls made it=
 run exactly how=0D=0AI wanted (and expected).  I'm guessing that the wx.Ti=
mer events are=0D=0Apropagating Update() calls to both frames within wx, wh=
ile the other two=0D=0Amethods aren't.  Except in Windows.  Hmm...  more re=
ading ahead for me.=0D=0A=0D=0AStill, most importantly (for me) my problem =
is solved, and I've learnt=0D=0Athings about wx events, and cross-platform =
issues.  Many thanks again=0D=0Afor your help, Matt - I'd have been flounde=
ring much longer without it.=0D=0ANow I'll try to solve some of the non-mat=
plotlib-related issues ;)=0D=0A=0D=0ACheers,=0D=0A=0D=0A--=20=0D=0ADr Leigh=
ton Pritchard AMRSC=0D=0AD131, Plant-Pathogen Interactions, Scottish Crop R=
esearch Institute=0D=0AInvergowrie, Dundee, Scotland, DD2 5DA, UK=0D=0AT: +=
44 (0)1382 562731 x2405 F: +44 (0)1382 568578=0D=0AE: lp...@sc....u=
k   W: http://bioinf.scri.sari.ac.uk/lp=0D=0AGPG/PGP: FEFC205C E58BA41B  ht=
tp://www.keyserver.net            =20=0D=0A(If the signature does not verif=
y, please remove the SCRI disclaimer)=0D=0A_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ =
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _=0D=0A=0D=0ADISCLAIMER:=0D=0A=0D=
=0AThis email is from the Scottish Crop Research Institute, but the views =0D=
=0Aexpressed by the sender are not necessarily the views of SCRI and its =0D=
=0Asubsidiaries.  This email and any files transmitted with it are confiden=
tial=20=0D=0Ato the intended recipient at the e-mail address to which it ha=
s been=20=0D=0Aaddressed.  It may not be disclosed or used by any other tha=
n that addressee.=0D=0AIf you are not the intended recipient you are reques=
ted to preserve this=20=0D=0Aconfidentiality and you must not use, disclose=
, copy, print or rely on this=20=0D=0Ae-mail in any way. Please notify post=
ma...@sc... quoting the=20=0D=0Aname of the sender and delete th=
e email from your system.=0D=0A=0D=0AAlthough SCRI has taken reasonable pre=
cautions to ensure no viruses are=20=0D=0Apresent in this email, neither th=
e Institute nor the sender accepts any=20=0D=0Aresponsibility for any virus=
es, and it is your responsibility to scan the email=20=0D=0Aand the attachm=
ents (if any).=0D=0A