matplotlib-users Mailing List for matplotlib

Hi:
The following script:
#!/usr/bin/env python
from matplotlib.matlab import *
figure(1)
plot([0],[0])
show()
gives this traceback:
Traceback (most recent call last):
 File 
"/usr/lib/python2.2/site-packages/matplotlib/backends/backend_gtkagg.py", 
line 75, in callback
 self.draw()
 File 
"/usr/lib/python2.2/site-packages/matplotlib/backends/backend_gtkagg.py", 
line 42, in draw
 agg.draw()
 File 
"/usr/lib/python2.2/site-packages/matplotlib/backends/backend_agg.py", 
line 299, in draw
 self.figure.draw(self.renderer)
 File "/usr/lib/python2.2/site-packages/matplotlib/figure.py", line 
128, in draw
 for a in self.axes: a.draw(renderer)
 File "/usr/lib/python2.2/site-packages/matplotlib/axes.py", line 603, 
in draw
 self.xaxis.draw(renderer)
 File "/usr/lib/python2.2/site-packages/matplotlib/axis.py", line 463, 
in draw
 tick.draw(renderer)
 File "/usr/lib/python2.2/site-packages/matplotlib/axis.py", line 130, 
in draw
 if self.label1On: self.label1.draw(renderer)
 File "/usr/lib/python2.2/site-packages/matplotlib/text.py", line 202, 
in draw
 ismath=self.is_math_text())
 File 
"/usr/lib/python2.2/site-packages/matplotlib/backends/backend_agg.py", 
line 203, in draw_text
 self._renderer.draw_text(
OverflowError: float too large to convert
If I remember correctly, there was a similar issue when 0.53 came out.
-- 
Peter Groszkowski Gemini Observatory
Tel: +1 808 974-2509 670 N. A'ohoku Place
Fax: +1 808 935-9235 Hilo, Hawai'i 96720, USA

On Tue, 2004年05月25日 at 17:11, Todd Miller wrote:
> On Tue, 2004年05月25日 at 11:13, John Hunter wrote:
> > >>>>> "Todd" == Todd Miller <jm...@st...> writes:
> > 
> > Todd> I tried porting anim.py to TkAgg this morning and got it
> > Todd> basically working. There are two things that might account
> > Todd> for the trouble you've been having:
> > 
> > Todd> 1. With TkAgg, at least for now, you have to call the
> > Todd> figure manager show() method with each cycle rather than the
> > Todd> canvas draw() method.
> > 
> > Would it be possible to reorganize tkagg so that a call to canvas.draw
> > also triggers a blit so that the interface could be more consistent
> > across backends?
> 
> I've been on leave a lot today but I'll take a look at this either this
> evening or tomorrow morning.
> 
This turned out to be really easy so now canvas.draw triggers a blit and
functions more like the other backends. It's in CVS. I also found an
extraneous draw() so performance should be better, perhaps 2x.
Cheers,
Todd

On Tue, 2004年05月25日 at 11:13, John Hunter wrote:
> >>>>> "Todd" == Todd Miller <jm...@st...> writes:
> 
> Todd> I tried porting anim.py to TkAgg this morning and got it
> Todd> basically working. There are two things that might account
> Todd> for the trouble you've been having:
> 
> Todd> 1. With TkAgg, at least for now, you have to call the
> Todd> figure manager show() method with each cycle rather than the
> Todd> canvas draw() method.
> 
> Would it be possible to reorganize tkagg so that a call to canvas.draw
> also triggers a blit so that the interface could be more consistent
> across backends?
I've been on leave a lot today but I'll take a look at this either this
evening or tomorrow morning.
Todd

> Gary: did Todd's example help you enough to speed you on your way?
>
> JDH
>
Well... I might say "yes", but you did put that word "speed" in there :)
If I run his code, it updates 1.5 frame per second. If I change the two
calls to
manager.canvas._tkcanvas.after(100, updatefig)
to
manager.canvas._tkcanvas.after(1, updatefig)
there is no difference in the speed.
FWIW, I'm on an 850MHz WinXP. IIRC, I get the same performance under linux
on the same machine.
You got five frames per second? When you say you improved performance
"without text" do you mean that you didn't label the axes?
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.
Finally, I'm not sure what he meant by "re-registering the handler with each
cycle". Does this mean call ....after() ?
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).
-gary

>>>>> "Todd" == Todd Miller <jm...@st...> writes:
 Todd> I tried porting anim.py to TkAgg this morning and got it
 Todd> basically working. There are two things that might account
 Todd> for the trouble you've been having:
 Todd> 1. With TkAgg, at least for now, you have to call the
 Todd> figure manager show() method with each cycle rather than the
 Todd> canvas draw() method.
Would it be possible to reorganize tkagg so that a call to canvas.draw
also triggers a blit so that the interface could be more consistent
across backends?
 Todd> 2. The Tk timed event system requires re-registering the
 Todd> handler with each cycle.
Or you can do something like this
 def updatefig(*args):
 updatefig.count += 1
 lines[0].set_ydata(X[:,updatefig.count%60])
 manager.show()
 return updatefig.count
 updatefig.count=-1
 while 1:
 cnt = updatefig()
 if cnt==100: break
 
 Todd> Performance was better than I thought it would be but still
 Todd> kinda slow.
I profiled this because it was slower than I expected. Turns out that
there is a huge performance hit in the changes I made to Text to
handle arbitrary rotations (a lot of time spent in Matrix getitem,
multiply, etc...). With text I could get only 5 frames per second;
w/o text I get 13 fps. The good news is that it will be easy to
optimize away most of the text based performance hit using more
efficient matrix operations and caching.
This can likely be improved further by using collections for drawing
markers in the line class.
Gary: did Todd's example help you enough to speed you on your way?
JDH

>>>>> "Gary" == Gary Ruben <ga...@em...> writes:
 Gary> Hi John, I probably didn't make it clear, but TkAgg has
 Gary> problems too. Here's what I know: Under 0.53.1 TkAgg and
 Gary> GTKAgg both worked fine, both when running the script
 Gary> directly from Windows Explorer in which case file
 Gary> association cause python to fire up in a DOS shell, and when
 Gary> running it from within SciTE or IDLE things are fine
 Gary> too. 0.54 has changed something.
Well, it's changed a lot. The big dollar question is which of these
changes are causing these problems :-)
 Gary> I tried grabbing and
 Gary> running a few examples from CVS as well as my own previously
 Gary> working examples. They behave consistently - GTKAgg no
 Gary> longer works at all
I need clarification here. What does it mean "no longer works at
all". If you open up a DOS command shell and run
 from matplotlib.matlab import *
 plot([1,2,3])
 show()
with 
 c:> python myscript.py -dGTKAgg
what happens? When you run from windows explorer and get a traceback,
you often lose the DOS window that provides the required information.
So it's best to debug from a command shell, though admittedly most of
the windows shells suck.
 Gary> and TkAgg works but only if I run it from DOS with a
 Gary> -dTkAgg option. It may be a GUI conflict but it has only
 Gary> started to conflict with 0.54. removing show() or replacing
 Gary> it with show(mainloop=False) seem to make no difference to
 Gary> the behaviour running TkAgg from SciTE. 
show(mainloop=False) would only be expected to have any effect with
GTK*, but I understand that it's not helping in that case either.
 Gary> I do notice that
 Gary> the python >>> prompt comes up in any DOS windows when
 Gary> running with the -dTkAgg option after the Tk plot window
 Gary> displays. Closing the window then leaves the python prompt
 Gary> and I have to ^Z it to shut it down. It's like it thinks it
 Gary> should be running in interactive mode, although 'interactive
 Gary> : False' is set in my .matplotlibrc This seems abnormal to
 Gary> me.
This is intentional. Since Tkinter doesn't have a mainloop, we switch
python to interactive mode after TkAgg finishes it's business and the
Tk window remains open until the python shell is closed.
 Gary> In my original post I asked if anyone else had success or
 Gary> problems in Win98 and since noone replied, maybe we can
 Gary> assume that I'm one of the rare users who's still using
 Gary> it. Therefore, as much as I (and probably you) would like to
 Gary> get to the bottom of what's happening, it's probably Win98
 Gary> specific and therefore, can probably wait; at least until
 Gary> after my upcoming exams are over and I get a chance to
I would be surprised if it's win98 specific. I haven't seen any
problems so far that were specific to just one windows OS. They're
basically all the same as far as I can see, Microsoft just keeps
shrinkwrapping them and recharging you for them :-) I have win98 at
home so I'll try and test a version there.
 Gary> really look into it some more. So I might go quiet for a few
 Gary> weeks unless you want me to try anything quick and specific.
 Gary> Finally, I hope you didn't lose the ecolor changes I made to
 Gary> errorbars and they might make it into a future version :-)
No, I missed them the first time but when cleaning out my inbox found
them and made an entry on the TODO list, so they'll get merged soon
enough. Thanks.
If you could try the command shell test with GTKAgg that I asked for
above, that would be great.
JDH

Hi John,
I probably didn't make it clear, but TkAgg has problems too.
Here's what I know:
Under 0.53.1 TkAgg and GTKAgg both worked fine, both when running the script directly from Windows Explorer in which case file association cause python to fire up in a DOS shell, and when running it from within SciTE or IDLE things are fine too. 0.54 has changed something. I tried grabbing and running a few examples from CVS as well as my own previously working examples. They behave consistently - GTKAgg no longer works at all and TkAgg works but only if I run it from DOS with a -dTkAgg option.
It may be a GUI conflict but it has only started to conflict with 0.54.
removing show() or replacing it with show(mainloop=False) seem to make no difference to the behaviour running TkAgg from SciTE.
I do notice that the python >>> prompt comes up in any DOS windows when running with the -dTkAgg option after the Tk plot window displays. Closing the window then leaves the python prompt and I have to ^Z it to shut it down. It's like it thinks it should be running in interactive mode, although 'interactive : False' is set in my .matplotlibrc
This seems abnormal to me.
In my original post I asked if anyone else had success or problems in Win98 and since noone replied, maybe we can assume that I'm one of the rare users who's still using it. Therefore, as much as I (and probably you) would like to get to the bottom of what's happening, it's probably Win98 specific and therefore, can probably wait; at least until after my upcoming exams are over and I get a chance to really look into it some more. So I might go quiet for a few weeks unless you want me to try anything quick and specific.
Finally, I hope you didn't lose the ecolor changes I made to errorbars and they might make it into a future version :-)
regards,
Gary
-- 
___________________________________________________________
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm