matplotlib-users Mailing List for matplotlib

Alexey Shamrin wrote:
> Why is GTKAgg is slower than GTK, but WXAgg is faster than WX?
My question exactly. It's unlikely that that Wx has to be slower than 
WxAgg. In theory, at least, wx can take advantage of hardware 
accelerated drawing. On the other hand, wx does not know about NumPy 
arrays of either flavor, so if the Agg wrappers do, they could have an 
advantage there. Also, wx is known to be much slower with numarray 
arrays than Numeric arrays. I'd would certainly recommend that wx users 
stick with Numeric if they don't have a compelling reason to use numarray.
Another issue is font caching. Is the wx back-end doing font caching? 
this made a huge difference in the wxPyPlot code.
By the way, timing drawing on X is difficult, because the drawing calls 
return after the app has told X what to draw, not when it has been 
drawn. I suspect this might have something to do with the 1000 fps that 
was measured.
I hope I'll get a chance to do some work on the wx backend someday....
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
 		
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

Hello!
Why is GTKAgg is slower than GTK, but WXAgg is faster than WX?
Alexey
On 2004年12月16日 10:23:26 -0600, John Hunter
<jdh...@ac...> wrote:
> import matplotlib
> matplotlib.use('GTKAgg')
> matplotlib.interactive(True)
> from matplotlib.matlab import *
> import time
> 
> x = arange(0,2*pi,0.01) # x-array
> axis([0.0,2*pi,-1.0,1.0]) # setup axis
> tstart = time.time()
> 
> line, = plot(x,sin(x))
> for i in arange(1,200):
> line.set_ydata(sin(x+i/10.0))
> draw()
> 
> print 'FPS:' , 200/(time.time()-tstart)
> 
> TkAgg 20 FPS
> GTK 50 FPS
> GTKAgg 36 FPS
> GTKCairo 15 FPS
> WX 11 FPS
> WXAgg 27 FPS

>>>>> "imaginee1" == imaginee1 <ima...@gm...> writes:
 imaginee1> Hi, we are trying to change from scipy.xplt to
 imaginee1> matplotlib and need advice on dynamic plots. With the
 imaginee1> examples at the end of this e-mail we get the following
 imaginee1> frame rates (PIV, 2.8 GHz, debian sarge, python 2.3,
 imaginee1> matplotlib 0.64)
 imaginee1> FPS xplt 1000 (mov_sin_xplt.py) TkAgg 20
 imaginee1> (mov_sin_mpl_tkagg.py) TkAgg2 5 (mov_sin_mpl_tkagg2.py)
 imaginee1> gtk 60 (mov_sin_mpl_gtk.py) gtkAgg 37
 imaginee1> (mov_sin_mpl_gtk.py)
1000 frames per second?? A typical top of the line monitor refreshes
at 75-100 FPS. How can you get 1000 frames per second? I'll humbly
suggest that you're not accurately measuring the true refresh rate of
xplt, while graciously acknowledging that xplt is much faster than
matplotlib.
Also, what refresh rate do you really need? DVD refreshes at 30FPS
and monitors typically around 75FPS. I suspect Andrew can tell us the
limits of the human visual system in terms of the maximal refresh rate
that is perceptible. I'm assuming you want to display these
animations to humans and not flies, which of course would be a
different story :-)
I certainly agree that there are things matplotlib can, should and
will do to make this process faster. The first problem is that the
entire figure is updated with every frame. It would be much more
efficient in animated mode to designate certain elements only for
update. These elements could store the background image of their
bounding box, and on each update erase themselves (restore the
background) and redraw themselves with the new data. By limiting
redraws to only sections of the canvas, and only certain plot
elements, we should be able to get at least a 2x speedup, I'm
guessing.
 imaginee1> More generally, our impression is that with matplotlib
 imaginee1> the code tends to be more complicated (timers, classes
 imaginee1> etc.) than the scipy.xplt version. Maybe there are
 imaginee1> better ways to achieve what we want (but we haven't
 imaginee1> found them yet ;-).
All this complication arises in attempting to deal with the mainloop.
You should be able to skip all this cruft, as you did for your tkagg
example, by running in interactive mode
 import matplotlib
 matplotlib.use('GTKAgg')
 matplotlib.interactive(True)
 from matplotlib.matlab import *
 import time
 x = arange(0,2*pi,0.01) # x-array
 axis([0.0,2*pi,-1.0,1.0]) # setup axis
 tstart = time.time()
 line, = plot(x,sin(x))
 for i in arange(1,200):
 line.set_ydata(sin(x+i/10.0))
 draw()
 print 'FPS:' , 200/(time.time()-tstart)
Basically what matplotlib needs is a method like
 for i in arange(1,200):
 line.set_ydata(sin(x+i/10.0))
 fig.update(line)
in place of the call to draw which redraws the entire figure.
 imaginee1> We also have a wx version, but the code is really
 imaginee1> complicated (any pointers on how to code our example
 imaginee1> most simply with the wx backend
 imaginee1> would be also very much appreciated).
Well, you'd have to post your code, but the interactive trick above
works for WX and WXAgg as well. But I doubt you'll beat GTK/GTKAgg
performance wise with WX*. With the example above, I get
 TkAgg 20 FPS
 GTK 50 FPS
 GTKAgg 36 FPS
 GTKCairo 15 FPS
 WX 11 FPS
 WXAgg 27 FPS
The performance problem with Tk animation is well known and w/o
resorting to platform dependent extension code, we don't have a good
way to solve it. 
Note in matplotlib's defense, the fact that I can run the same
animated code across platforms and 4 GUIs (FLTK not profiled here) w/o
changing a single line of code says something about why it's slower
that xplt, which targets a single windowing system and thus can make
low level calls.
JDH

>>>>> "Gary" == Gary <pa...@in...> writes:
 from numerix import MLab, absolute, arange, array,
 ImportError: cannot import name
This looks like a bug. Right before the release I cleaned up axes.py
because the numerix min should not be mixed with the builtin min.
Hence I did
 # do not import numerix max! we are using python max. 
 from numerix import MLab, absolute, arange, array, asarray, ones, transpose, \
 log, log10, Float, ravel, zeros, Int32, Float64, ceil, min, indices, \
 shape, which
 from numerix import max as nxmax
 from numerix import min as nxmin
I should have also remove min from the numerix import (oversight),
which I already caught and fixed in CVS thanks to pychecker.
So removing "min" from the numerix import in axes.py should fix your
problem, but\ I'm surprised that you are unable to import min from the
numerix module. So before you fix it could you run a test script with
 > python myscript.py --verbose-helpful
and report the output, particularly the numerix version information.
Perhaps Todd or I can then offer some insight into why the MLab.min
function is not in the numerix namespace. I can do
 >>> from matplotlib.numerix import min
with both Numeric and numarrary (latest release or CVS of both). My
guess is that you cannot, and I'd like to know why.
You appear cursed in your ability to get a working matplotlib win32
upgrade! Maybe next time....
JDH

Hi,
we are trying to change from scipy.xplt to matplotlib and
need advice on dynamic plots.
With the examples at the end of this e-mail we get the following
frame rates (PIV, 2.8 GHz, debian sarge, python 2.3, matplotlib 0.64)
 FPS
xplt 1000 (mov_sin_xplt.py)
TkAgg 20 (mov_sin_mpl_tkagg.py)
TkAgg2 5 (mov_sin_mpl_tkagg2.py)
gtk 60 (mov_sin_mpl_gtk.py)
gtkAgg 37 (mov_sin_mpl_gtk.py)
We also have a wx version, but the code is really complicated
(any pointers on how to code our example most simply with the wx backend
would be also very much appreciated).
Obviously, our matplotlib implementations run much
slower than scipy.xplt. Do you have any suggestions
on how we could improve the speed of the code?
More generally, our impression is that with matplotlib
the code tends to be more complicated (timers, classes etc.)
than the scipy.xplt version. Maybe there are
better ways to achieve what we want (but we haven't found them yet ;-).
Personally we don't mind too much about using classes, timers and events,
but
we want to replace scipy.xplt in a course on computational physics.
Most of the students have not been exposed to these concepts before,
so we have to avoid that completely.
Our experiences with scipy.xplt were very positive
as it allows a `linear programming style', which is very suitable
for beginners.
Best,
Lars and Arnd
###############################################
## mov_sin_xplt.py
from scipy.xplt import *
import time
x = arange(0,2*pi,0.01) # x-array
window(wait=1) # wait for plotting
animate(1) # use blitting
tstart = time.time()
for i in arange(10000):
 plg(sin(x+i/100.0),x,marks=0) # plot the function
 fma() # blit the offscreen pixmap
print 'FPS:' , 10000/(time.time()-tstart)
###############################################
## mov_sin_mpl_tkagg.py
import matplotlib
matplotlib.use('TkAgg')
matplotlib.interactive(True)
from matplotlib.matlab import *
from Numeric import *
import time
x = arange(0,2*pi,0.01) # x-array
lines = plot(x,sin(x)) # plot the function
axis([0.0,2*pi,-1.0,1.0]) # setup axis
tstart = time.time()
for i in arange(200):
 lines[0].set_ydata(sin(x+i/10.0)) # change y-data
 draw() # force redraw
print 'FPS:' , 200/(time.time()-tstart)
###############################################
## mov_sin_mpl_tkagg2.py
import matplotlib
matplotlib.use('TkAgg')
matplotlib.interactive(True)
from matplotlib.matlab import *
from Numeric import *
import time
x = arange(0,2*pi,0.01) # x-array
axis([0.0,2*pi,-1.0,1.0]) # setup axis
tstart = time.time()
or i in arange(200):
 clf()
 plot(x,sin(x+i/10.0))
print 'FPS:' , 200/(time.time()-tstart)
###############################################
## mov_sin_mpl_gtk.py
import matplotlib
matplotlib.use('GTKAgg') # matplotlib.use('GTK')
from matplotlib.matlab import *
from Numeric import *
import gtk
import time
x = arange(0,2*pi,0.01) # x-array
lines = plot(x,sin(x))
axis([0.0,2*pi,-1.0,1.0])
manager = get_current_fig_manager()
tstart = time.time()
def updatefig(*args):
 updatefig.count += 1
 lines[0].set_ydata(sin(x+updatefig.count/10.0))
 manager.canvas.draw()
 if updatefig.count>1000:
 print 'FPS:' , 1000/(time.time()-tstart)
 return gtk.FALSE
 return gtk.TRUE
updatefig.count=-1
gtk.idle_add(updatefig)
show()
-- 
GMX ProMail mit bestem Virenschutz http://www.gmx.net/de/go/mail
+++ Empfehlung der Redaktion +++ Internet Professionell 10/04 +++

On 2004年12月15日, Gary apparently wrote:
> from pylab import *
Either first import everything from matplotlib
or do instead
from matplotlib.pylab import *
hth,
Alan Isaac

As is becoming usual, my attempt to upgrade has run into a problem.
WinXP,
deleted previous ...\matplotlib before installing.
None of the examples (from the new zip file) seem to run. They 
generally seem to start with
from pylab import *
but this fails, even from the command line. Bug, feature, or pilot 
error? :)
-gary
----------------------------------------------------------
C:\Python23\Lib\site-packages\matplotlib\examples>python
Python 2.3.4 (#53, May 25 2004, 21:17:02) [MSC v.1200 32 bit (Intel)] on 
win32
Type "help", "copyright", "credits" or "license" for more information.
 >>> from pylab import *
Traceback (most recent call last):
 File "<stdin>", line 1, in ?
 File "C:\Python23\Lib\site-packages\pylab.py", line 1, in ?
 from matplotlib.pylab import *
 File "C:\Python23\Lib\site-packages\matplotlib\pylab.py", line 184, in ?
 from axes import Axes, PolarAxes
 File "C:\Python23\Lib\site-packages\matplotlib\axes.py", line 6, in ?
 from numerix import MLab, absolute, arange, array, asarray, ones, 
transpose,
 \
ImportError: cannot import name min

On Wed, 2004年12月15日 at 16:49 -0600, John Hunter wrote:
> >>>>> "Eli" == Eli Glaser <eg...@se...> writes:
> 
> Eli> Hello, Is there an easy way to set the initial position of a
> Eli> Figure? I'm using Windows XP and new figures seem to pop up
> Eli> in the typical Windows fashion where subsequent figures
> Eli> appear about 20 pixels down and 20 pixels to the right of
> Eli> previous figures. How can I tell each figure where to pop up
> Eli> on screen?
> 
> matplotlib doesn't provide explicit support for this, but it is
> possible. What backend are you using. The matplotlib Figure is
> embedded in a FigureCanvas which is typically a GUI widget embedded in
> a GUI Window. In the pylab interface, the canvas is managed by a
> FigureManager, which has a window attribute on most of the backends.
> 
> Eg for the GTK backend, for example, you could do
> 
> from pylab import *
> 
> import gtk
> 
> figure(1)
> plot([1,2,3])
> manager = get_current_fig_manager()
> 
> # see gtk.Window class docs at
> # http://www.pygtk.org/pygtk2reference/class-gtkwindow.html
> manager.window.set_position(gtk.WIN_POS_CENTER)
> 
> figure(2)
> plot([1,2,3])
> manager = get_current_fig_manager()
> 
> # see gtk.Window class docs at
> # http://www.pygtk.org/pygtk2reference/class-gtkwindow.html
> manager.window.set_position(gtk.WIN_POS_NONE)
> 
> show()
> 
> For the WX* backend, manager.window is a wxFrame -
> http://www.lpthe.jussieu.fr/~zeitlin/wxWindows/docs/wxwin_wxframe.html#wxframe
> 
> For the TkAgg backend, manager.window is a Tkinter.Tk instance -
> http://starship.python.net/crew/fredrik/tkclass/ClassToplevel.html
>
> Off the top of my head I don't know the right incantation for each
> backend, but hopefully the classdocs I referenced above will help.
> Perhaps Todd or Matthew can chime in with more Tk and WX information.
In TkAgg it works like this:
get_current_fig_manager().window.wm_geometry("+200+300")
To set the window position to X=200, Y=300.
Todd