matplotlib-users Mailing List for matplotlib

Dear John,
thank you very much for your helpful answer!
On 2004年12月16日, John Hunter wrote:
> >>>>> "imaginee1" == imaginee1 <ima...@gm...> writes:
[... snip frame rates ...]
> 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 :-)
That would be an interesting research project, but
makes grant applications more complicated due to animal experiments ;-).
The FPS numbers give us an estimate on the speed of
the drawing process (see also below).
> 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.
We have a question here concerning the example you gave: is
the whole screen updated with every `draw()`,
including the axes and labels?
If so there might be another (simpler) possibility
by just updating the white plot-area.
A problem might be the inward pointing tics.
((For the PlottingCanvas we solved this by having
ticks pointing outward and using a separate frame
for the inside of the plot)).
> 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)
This is indeed very nice and works (basically) the same for all backends.
For this particular example we get:
 Double buffered Resizable
xplt no no
tkagg yes yes
gtk yes (but: frameshift) no
gtkagg no no
wx no no
wxagg no no
Interestingly, in this dynamics example
tkagg and gtk seem to have double buffering,
i.e. at the end of the dynamics a damaged area gets repainted.
With tkagg one can even resize the window at the end of the
dynamics.
(Actually, in the examples we posted double-buffering and resizing
worked).
Just a remark: For the gtk backend the double-buffer for
the repaint is one frame behind.
> 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.
That could indeed give an substantial speed-up.
> 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*.
We will either need Tk or WX for our Windows using students.
For Linux GTKAgg should do the job.
> 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.
I re-ran the tests on my laptop (PIII, 1.2 GHz)
 John laptop
 xplt 196
 TkAgg 20 FPS 9
 GTK 50 FPS 25
 GTKAgg 36 FPS 18
 WX 11 FPS 8
 WXAgg 27 FPS 11
(Unfortunately, some of the students have even slower machines ;-(.
To provide even more data (now a PIV, 2.8 GHz, debian sarge,
but a different X driver, factor 3 slower for xplt!)
 1000 pts 10000 pts 100000 pts
xplt 330 FPS 159 FPS 43 FPS
tkagg 23 FPS 16 FPS 4 FPS
gtk 40 FPS 19 FPS 5 FPS
gtkagg 31 FPS 24 FPS 4 FPS
wx 12 FPS 3 FPS 0 FPS
wxagg 24 FPS 16 FPS 4 FPS
This shows the FPS when the number of points being plotted
is increased.
To answer your question from above:
Something like 40 FPS for plotting 10000 points
would be optimal. On slower machines (like
my laptop) this might not be realizable.
> 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.
There is really no need to defend matplotlib
(and we better don't post matplotlib's feature list here
to emphasize the points we like!).
Best,
Nikolai and Arnd

On Thu, 2004年12月16日 at 20:21 +0300, Alexey Shamrin wrote:
> Why is GTKAgg is slower than GTK, but WXAgg is faster than WX?
Were you thinking that GTKAgg should be as fast or faster than GTK? 
In the past I think GTKAgg and GTK would do dynamic plots at about the
same speed. GTK used to allocate a new gtk.gdk.Pixmap and a new
RendererGTK for every figure draw operation, which was inefficient. I
updated the code so GTK now creates just one RendererGTK and just one
Pixmap (as long as its size does not increase). This should have made
GTK dynamic plotting faster (I didn't benchmark the changes so I don't
know for sure).
Its possible that similar changes for GTKAgg (or TkAgg or WX) would
speed up their dynamic plotting.
Steve

>>>>> "Gary" == Gary <pa...@in...> writes:
 Gary> ---------------------------------------------------------------------
 Gary> C:\Python23\Lib\site-packages\matplotlib\examples>python
 Gary> Python 2.3.4 (#53, May 25 2004, 21:17:02) [MSC v.1200 32 bit
 Gary> (Intel)] on win32 Type "help", "copyright", "credits" or
 Gary> "license" for more information.
 >>>> from matplotlib.numerix import min
 Gary> Traceback (most recent call last): File "<stdin>", line 1,
 Gary> in ? ImportError: cannot import name min
 Gary> ----------------------------------------------------------------
It looks like your Numeric install is screwed up. Remove
site-packages Numeric to be on the safe side and grab the latest
release for your python version at 
 http://sourceforge.net/projects/numpy
reinstall and see if that fixes your problem. Let me know...
JDH

John Hunter wrote:
>[...]
>
>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.
> 
>
---------------------------------------------------------------------
C:\Python23\Lib\site-packages\matplotlib\examples>python simple_plot.py 
--verbose-helpful
matplotlib data path C:\Python23\share\matplotlib
loaded rc file C:\Python23\share\matplotlib\.matplotlibrc
matplotlib version 0.65
verbose.level helpful
interactive is False
platform is win32
numerix Numeric 23.0
Traceback (most recent call last):
 File "simple_plot.py", line 3, in ?
 from pylab import *
 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
-----------------------------------------------------------------------------------
>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
>
> 
>
correct:
---------------------------------------------------------------------
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 matplotlib.numerix import min
Traceback (most recent call last):
 File "<stdin>", line 1, in ?
ImportError: cannot import name 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....
> 
>
Off topic comment: I have a number or little annoyances with various 
packages. Enough that I decided that I would try migrating to Linux. 
My Thinkpad has only a modest HD, so I didn't want to partition it. I 
could buy a bigger drive. But my Thinkpad can boot from an external USB 
device, so I started wondering if I could set up a Linux entirely on the 
external drive, and not touch my internal drive. If it worked, I'd have 
a portable Linux (portable, at least, to any machine that can boot from 
USB). 
I searched the web, and found mixed reviews concening the viability of 
this idea.
So I bought a USB enclosure (10ドル on eBay) and a 20 GB drive (33ドル on 
eBay, but read on) and went to town. After about three months of 
back-burner late-night tinkering, I got it working! A week later, my 
external HD crashed. I'm waiting for some extra time to appear before 
trying again.
If anyone is interested, I can provide some pointers. (once I'm 
finished, I'll post my experinces on a web site somewhere) Two initial 
comments: 1.) be very careful about buying a "Travelstar" HD on eBay. 
Apparantly manufacturing problems resulted in a large number of faulty 
units getting into circulation. 2.) I was *not* successful using 
Mandrake or Mepis. I was successful using Fedora FC2.