From: <ima...@gm...> - 2004-12-16 11:24:54
|
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 +++ |
From: John H. <jdh...@ac...> - 2004-12-16 16:26:08
|
>>>>> "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 |
From: Arnd B. <arn...@we...> - 2004-12-17 18:37:20
|
Dear John, thank you very much for your helpful answer! On Thu, 16 Dec 2004, 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 |
From: <ima...@gm...> - 2004-12-21 17:49:54
|
Hi, after spending a nice afternoon profiling the dynamic examples and looking a bit through the code, we can make a few comments on the performace of the wx backends. We have used kcachegrind to display the results of hotshot - all files can be found under http://www.physik.tu-dresden.de/~baecker/tmp/profiling/ WXAgg (http://www.physik.tu-dresden.de/~baecker/tmp/wxagg.png): WxAgg leaves the composition of the plot frame to the agg backend and blits the calculated picture to the screen. The agg backend seems to be quite efficient since we could not find any predominant bottleneck. But, agg and wx use different image formats, therefore the picture has to be transformed using wx.Image.ConvertToBitmap which is a deprecated wx method. On the other hand, gtk-agg uses the C++ routine agg_to_gtk_drawable which seems to be faster. Optimising the agg to wxPython conversion could lead to a similar speedup. Because wxAgg leaves the drawing to agg it is faster than the wx backend. WX (http://www.physik.tu-dresden.de/~baecker/tmp/profiling/wx.png): As Chris Barker correctly presumed the wx backend doesn't do any caching. Therefore about 15% of program time is spent in the freetype2 library (ft2font.FT2Font) and another 7% for changing wxPens wxBrushes and sizes. So storing all this information on the python level (and only altering it if there is a change) would lead to a first performance increase. (draw_text and set_foreground branch in the picture) The wx device context (wxDC) is not passed as local variable or instanced as global but selected for every drawing operation and unselected afterwards. (new_gc branch) The drawXXXs (note the plural) commands in wx expect the input to be an array of points. The following line of code is from the wx-backend. > gc.DrawLines([wxPoint(int(x[i]), self.height - int(y[i])) for i in range(len(x))]) Avoiding the explicit loop and vectorizing the expression should give another speed increase (_draw_solid branch). Best, Nikolai and Arnd -- +++ Sparen Sie mit GMX DSL +++ http://www.gmx.net/de/go/dsl AKTION für Wechsler: DSL-Tarife ab 3,99 EUR/Monat + Startguthaben |
From: John H. <jdh...@ac...> - 2004-12-21 19:52:31
|
>>>>> "imaginee1" == imaginee1 <ima...@gm...> writes: imaginee1> Hi, after spending a nice afternoon profiling the imaginee1> dynamic examples and looking a bit through the code, we imaginee1> can make a few comments on the performace of the wx imaginee1> backends. We have used kcachegrind to display the imaginee1> results of hotshot - all files can be found under imaginee1> http://www.physik.tu-dresden.de/~baecker/tmp/profiling/ Hi Arnd, thanks for your profiling information - I very much like the hotshot graphs! I just have two comments. All of your suggestions are imminently reasonable. The major problem is that the wx backend has been mostly rudderless since Jeremy, the author, stopped maintaining it, though I've filled in when I can. Matthew Newville has recently signed on as the new maintainer and has CVS commit privileges, but I don't know how much time he has to address these issues right now. I don't have any extra time to devote to wx optimizations, currently. If you would like to do some work here, I would be happy to add you to the developers list. The second point is that in your previous email you appeared to indicate that GTK wasn't a good option for you because many of your students use win32. I use the gtk backend on win32 - you have to run the GTK runtime installer and the pygtk installer, but it otherwise works great, and the matplotlib gtk extension code is compiled into the matplotlib win32 installer. There are install instructions for win32 at http://matplotlib.sourceforge.net/backends.html#GTK . JDH |
From: Matt N. <new...@ca...> - 2004-12-22 04:34:23
|
Hi Arnd, John, all, Thanks for the profiling information on WX and WXAgg backends, and sorry I haven't been able to participate in this conversation more. I've been running experiments for several weeks, and am definitely looking forward to a break! Hopefully I'll be able to devote some time to this in January. I'm really not a wx or matplotlib expert, buit I am definitely interested in getting WX or WXAgg to go faster. Re-drawing line scans at 15Hz would be plenty fast enough for my needs but I would like that to include rescaling the axes as well as updating the line (which is what most of the current benchmarks test). Refreshing relatively small images at 1Hz would be OK for me - I think that's already good enough for me. Also, I'll have to admit my timeframe is probably going to be slower than many people on this list! So if you or someone else wants to jump in, that would be fine with me. I agree that the Agg rendering itself does not seem like the bottleneck for WXAgg. Partly because of that, I'm assuming that the WXAgg will be good enough for my needs (as opposed to completely rewriting backend_wx) and that getting to GTKAgg level of performance would be the goal. I also agree that the best solution is likely to mean converting the Agg image (pixBuffer??) into the wx.bitmap in c++. I'm not sure I have a firm grasp on how exactly to do that, but it's worth trying. --Matt |
From: Arnd B. <arn...@we...> - 2004-12-22 14:44:47
|
Hi Matt, On Tue, 21 Dec 2004, Matt Newville wrote: [...] > I agree that the Agg rendering itself does not seem like the > bottleneck for WXAgg. Partly because of that, I'm assuming that > the WXAgg will be good enough for my needs (as opposed to > completely rewriting backend_wx) and that getting to GTKAgg level > of performance would be the goal. I also agree that the best > solution is likely to mean converting the Agg image (pixBuffer??) > into the wx.bitmap in c++. I'm not sure I have a firm grasp on > how exactly to do that, but it's worth trying. We did some more profiling (see the other mail) which confirms that the calls to ConvertTotBitmap and wxEmptyImage are the main difference to GTKAgg. The best would be to directly blit the Agg image onto the wxFrame (however this assumes that these are of the same type, which we don't know. If not, the C++ route should be the fastest. Unfortunately we both don't speak C++ and cannot help further here). Best, Nikolai and Arnd |
From: Chris B. <Chr...@no...> - 2004-12-22 16:59:24
|
Matt Newville wrote: > I also agree that the best > solution is likely to mean converting the Agg image (pixBuffer??) > into the wx.bitmap in c++. This trick here is that the binary format of a wxBitmap is both platform and instance dependent. The idea, as I understand it, is that a wxBitmap has the same binary format as is needed for the current display, so each platform is different, and it can also be different depending on the depth of the display. Given all this, I doubt you're going to be able to improve on the wx supplied methods for converting from a wxImage to a wxBitmap. (and if you do, contribute it to wx!) Does the Agg backend use a binary format compatible with wxImage? If not, that means there are two conversions required, which might be the source of the slowdown. -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... |
From: John H. <jdh...@ac...> - 2004-12-22 17:28:05
|
>>>>> "Chris" == Chris Barker <Chr...@no...> writes: Chris> This trick here is that the binary format of a wxBitmap is Chris> both platform and instance dependent. The idea, as I Chris> understand it, is that a wxBitmap has the same binary Chris> format as is needed for the current display, so each Chris> platform is different, and it can also be different Chris> depending on the depth of the display. Given all this, I Chris> doubt you're going to be able to improve on the wx supplied Chris> methods for converting from a wxImage to a wxBitmap. (and Chris> if you do, contribute it to wx!) But this might helpful - if we can detect what kind of binary format wx is using, we can ask agg to convert itself to this format in a python buffer object and pass this on directly to the wxBitmap. Agg has efficient conversion routines from just about any pixel format to any other. This would avoid one copy, because we could do (making up the syntax for copying a buffer into the bitmap FigureCanvasAgg.draw(self) if display_format=='ZZZ': # made up pixel format buffer = self.to_zzz() self.bitmap.UpdateFromBuffer(buffer) # made up method else: # fall back on old method s = self.tostring_rgb() w = int(self.renderer.width) h = int(self.renderer.height) image = wxEmptyImage(w,h) image.SetData(s) self.bitmap = image.ConvertToBitmap() self.gui_repaint() If we could handle the most common cases, it would be a win for most users. Any idea how to query the pixel format of the wx display? Chris> Does the Agg backend use a binary format compatible with Chris> wxImage? If not, that means there are two conversions Chris> required, which might be the source of the slowdown. agg uses an array of unsigned chars r0, b0, g0, a0, r1, b1, g1, a1, ... What does wxImage use? JDH |
From: Arnd B. <arn...@we...> - 2004-12-22 14:43:10
|
Hi John, On Tue, 21 Dec 2004, John Hunter wrote: > >>>>> "imaginee1" == imaginee1 <ima...@gm...> writes: > > imaginee1> Hi, after spending a nice afternoon profiling the > imaginee1> dynamic examples and looking a bit through the code, we > imaginee1> can make a few comments on the performace of the wx > imaginee1> backends. We have used kcachegrind to display the > imaginee1> results of hotshot - all files can be found under > imaginee1> http://www.physik.tu-dresden.de/~baecker/tmp/profiling/ > > Hi Arnd, thanks for your profiling information - I very much like the > hotshot graphs! Nikolai and I were also quite impressed, in particular because there is another window in which one can see the corresponding lines of code, including timings (even down to the wxpython level!). However, we don't understand the output completely. One reason certainly is that we don't know the matplotlib code well enough. Another reason is that there might be some glitches (either kcachegrind or the conversion script). We just did some more profiling, for TkAgg, GTK, GTKAgg, WX and WXAgg, see: http://www.physik.tu-dresden.de/~baecker/tmp/profiling2/ From this we get for all **Agg backends that - new_gc - _draw_solid - draw_text eat up a major part of the time. Another important part is spread in the draw chain (for example from 74.3% in to 47.0 %+10.3 % in GTKAgg). Best, Nikolai and Arnd P.S: we just looked at backend_gtk.py. Couldn't one safely replace def draw_lines(self, gc, x, y): x = x.astype(nx.Int16) y = self.height*ones(y.shape, nx.Int16) - y.astype(nx.Int16) self.gdkDrawable.draw_lines(gc.gdkGC, zip(x,y)) by def draw_lines(self, gc, x, y): x = x.astype(nx.Int16) y = self.height - y.astype(nx.Int16) self.gdkDrawable.draw_lines(gc.gdkGC, zip(x,y)) ? It might give a small improvement. P.P.S: Thanks for mentioning good experiences with GTK under Windows - we will give it a try. |
From: Steve C. <ste...@ya...> - 2004-12-22 17:32:44
|
On Wed, 2004-12-22 at 15:43 +0100, Arnd Baecker wrote: >From this we get for all **Agg backends that > - new_gc > - _draw_solid > - draw_text > eat up a major part of the time. > Another important part is spread in the draw chain > (for example from 74.3% in to 47.0 %+10.3 % in GTKAgg). I've noticed that that new_gc() is called many times (60 times when running simple_plot.py) with each call creates a new GraphicsContext instance. I think it would be more efficient to create just one GC instance and reuse it. It would suit the way that the Cairo, PS and possibly SVG and Agg backends do their drawing but that might mean completely changing the way the matplotlib frontend does its drawing. > P.S: we just looked at backend_gtk.py. > Couldn't one safely replace > > def draw_lines(self, gc, x, y): > x = x.astype(nx.Int16) > y = self.height*ones(y.shape, nx.Int16) - y.astype(nx.Int16) > self.gdkDrawable.draw_lines(gc.gdkGC, zip(x,y)) > > > by > > def draw_lines(self, gc, x, y): > x = x.astype(nx.Int16) > y = self.height - y.astype(nx.Int16) > self.gdkDrawable.draw_lines(gc.gdkGC, zip(x,y)) > > ? It might give a small improvement. I hope so because I made this change to the code a few weeks ago and it is now in the file backend_gdk.py in matplotlib 0.65! It looks like you are running an old version of matplotlib. Steve |
From: Arnd B. <arn...@we...> - 2004-12-22 17:49:09
|
On Thu, 23 Dec 2004, Steve Chaplin wrote: [...] > > P.S: we just looked at backend_gtk.py. > > Couldn't one safely replace > > > > def draw_lines(self, gc, x, y): > > x = x.astype(nx.Int16) > > y = self.height*ones(y.shape, nx.Int16) - y.astype(nx.Int16) > > self.gdkDrawable.draw_lines(gc.gdkGC, zip(x,y)) > > by > > > > def draw_lines(self, gc, x, y): > > x = x.astype(nx.Int16) > > y = self.height - y.astype(nx.Int16) > > self.gdkDrawable.draw_lines(gc.gdkGC, zip(x,y)) > > > > ? It might give a small improvement. > I hope so because I made this change to the code a few weeks ago and it > is now in the file backend_gdk.py in matplotlib 0.65! > It looks like you are running an old version of matplotlib. Well, 0.64 ;-) Last week, before we started with this, there were no debian packages for 0.65. But now they are, http://anakonda.altervista.org/debian/ Sorry for the duplication ... |
From: Alexey S. <sh...@gm...> - 2004-12-16 17:21:17
|
Hello! Why is GTKAgg is slower than GTK, but WXAgg is faster than WX? Alexey On Thu, 16 Dec 2004 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 |
From: Chris B. <Chr...@no...> - 2004-12-16 19:49:37
|
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... |
From: Steve C. <ste...@ya...> - 2004-12-17 16:41:08
|
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 |