matplotlib-users Mailing List for matplotlib

> I agree. The current design of matplotlib doesn't really support this
> kind of use because it redraws the entire figure every time and does
> too much duplicate work at the python level. It shouldn't be too hard
> to add some specialized functions for agg that support strip charts.
> I've been planning to do it because we have a need for it here, and
> there is some general on c.l.python for this kind of plotting feature
> in python.
>
> So I can start mulling over the design, can you tell me what kinds of
> real time updates you need - only solid lines or arbitrary symbols
> like 'o' too? Anything else besides line plots?
>
> I'm envisioning some extension code that talks directly to the data
> source and to the agg backend, updating only part of the canvas. The
> blitting functions for GTK/WX/Tk Agg would have to be extended to blit
> only a region of the canvas.
We'd also be interested in updates to real-time graph capabilities. 
We've just started examining Python + wxPython as a platform for 
control of some of our robotic systems. I've gotten a real-time bar 
graph running now, but it's awfully inefficient. I modified the basic 
dynamic_demo_wx.py file to update regularly, and at a forced 10 FPS it 
locks out the wxPython interface on my dual 2 GHZ Mac G5. No way it 
should do that ...
We'd also be interested in strip charts, mostly line based. We'd want 
to do multiple lines per chart. A capability to move through time, or 
zooming, might be useful, but certainly not necessary in a first rev 
(just mentioning it for now).
For bar graphs, we have to update at a given rate (typically up to 
about 25Hz), with different colors per bar (I have yet to do this part 
in the example I'm working on - think of multilpe temperatures being 
displayed, and different colors indicating different zones, per bar; 
nominal, caution, danger).
Having said all that, we're currently using wxPython, and I don't yet 
understand how AGG fits in the picture with matplotlib. :-(
TIA
Stephen

On Fri, 2004年05月28日 at 10:56, John Hunter wrote:
> >>>>> "Gary" == Gary Pajer <pa...@in...> writes:
> 
> Gary> I took out a wristwatch and timed it instead of guessing. I
> Gary> get three frames per second. It's about 4x from where we
> Gary> started, but still slow. I guess I'm just underpowered,
> Gary> although a couple of years ago this was a powerhouse. It
> Gary> seems that matplotlib may not be suited to this task. I
> Gary> don't think it should take 2 GHz just to power a stripchart.
> 
> One more comment here, mainly for Todd. 
> 
> Todd, I get 34 FPS on anim.py with GTKAgg and only 21 FPS with the
> anim_tk.py, where both scripts are doing the same thing. The profiler
> reveals a good chunk of the time is in
> 
> 103 2.300 0.022 2.300 0.022 tkagg.py:4(blit)
> 
> This may be a tk limitation, but I just wanted to point it out to you
> in case there are any optimizations you can apply to that function.
I tried a few things, but I didn't find anymore performance blunders 
so barring the kind of optimization Perry mentioned, I think we're
stuck. I think most of the time is going into Tk_PhotoPutBlock.
> I'll include the anim_tk.py I'm using for profiling below.
I only got 11-12 FPS (for tkagg) on a 1.7 Ghz Pentium-IV...
Todd

>>>>> "Flavio" == Flavio Codeco Coelho <fcc...@fi...> writes:
 Flavio> Matplotlib 0.54.1 still has trouble plotting column or row
 Flavio> vectors:
Try replacing matplotlib.lines.set_data with the following and let me
know if it passes all your tests. You will need to add ravel to the
list of functions imported from numerix at the top of the lines
module.
 def set_data(self, x, y):
 try: del self._xc, self._yc
 except AttributeError: pass
 self._x = asarray(x, Float)
 self._y = asarray(y, Float)
 if len(self._x.shape)>1: self._x = ravel(self._x)
 if len(self._y.shape)>1: self._y = ravel(self._y)
 if len(self._y)==1 and len(self._x)>1:
 self._y = self._y*ones(self._x.shape, Float)
 if self._useDataClipping: self._xsorted = self._is_sorted(self._x)
Thanks!
JDH

I'll get this one. I also have some tkagg/setupext related changes for
Mac OS-X.
Todd
On Fri, 2004年05月28日 at 12:55, Anthony Joseph Seward wrote:
> The default location for the tk include files is missing. The attached
> patch fixes it.

The default location for the tk include files is missing. The attached
patch fixes it.

>>>>> "James" == James Boyle <bo...@ll...> writes:
 James> Until contouring is implemented, the only way to display 2D
 James> data is by pcolor. I have two observations:
 James> (1) While trying to figure out exactly what pcolor was
 James> doing ( I did not understand the grid registration) I
 James> looked into the matlab documentation. The matlab docs
 James> explained what was going on, so that I could get my values
 James> properly aligned on the grid. This brings up a question -
 James> How close does matplotlib follow Matlab? Will there always
 James> be such a close correspondence in the implementation of
 James> functions such as I found in pcolor?
The matlab interface tries to follow matlab pretty closely, but not
religiously. For example, in matlab you can say
 plot(x,Y) 
where Y is MxN and it will plot all the data in the array. matplotlib
doesn't handle this case, currently. In the case of errorbar, it made
more sense to extend the features (eg to support x and y asymmetric
errorbars) than slavishly follow the matlab signature. 
All other things being equal I try and implement the matlab signature.
It's usually a good motivator because it encourages you to add
features at design time that you might be tempted to leave out.
Why do you ask?
 James> (2) To do quantitative representation using pcolor, a
 James> colorbar function is needed. This feature does not appear
 James> on the list of future goals, I would like it to be
 James> added. I'm not that competent, but I will give it a try
 James> myself. The first few easy things I tried did not work out.
Agreed. I just implemented this. Unzip the following in your
site-packages dir
 http://nitace.bsd.uchicago.edu:8080/files/share/matplotlib.py-0.54.2a.zip
After you have created a pcolor, just do 
 colorbar()
This will resize your axes to make room for the colorbar and display a
vertical colorbar (I haven't yet supported horizontal colorbars, as
matlab does). If you want to use non-default limits for the colormap,
call cmap.set_clim(cmin, cmax) before the pcolor and colorbar, as in
this example
 cmap = ColormapJet(256)
 cmap.set_clim(cmin, cmax)
 pcolor(Z, cmap=cmap)
 colorbar()
Let me know how it goes!
JDH

John Hunter writes
> One more comment here, mainly for Todd. 
> 
> Todd, I get 34 FPS on anim.py with GTKAgg and only 21 FPS with the
> anim_tk.py, where both scripts are doing the same thing. The profiler
> reveals a good chunk of the time is in
> 
> 103 2.300 0.022 2.300 0.022 tkagg.py:4(blit)
> 
> This may be a tk limitation, but I just wanted to point it out to you
> in case there are any optimizations you can apply to that function.
> 
> I'll include the anim_tk.py I'm using for profiling below.
> 
> Cheers,
> JDH
 
I do believe it is a limitation of the tk api (which the
blitting code uses) that makes writing to pixels of the 
tk window comparatively slow. It is possible to come up
with a tk interface using tkinter3000( aka wck) and some
hairy code to write directly to the window buffer. Eric
Jones has done this for the chaco implementation. Porting
it to matplotlib would take some work (how much I'm not
quite sure). It is isn't important to us right now so
we aren't going to do it for some time. If someone else
is interested they are welcome to. It does mean writing
a C or C++ implementation for each platform (i.e., X, win32, 
aqua). I know that the blitting can be improved by more 
than an order of magnitude in this way.
Perry

>>>>> "Gary" == Gary Pajer <pa...@in...> writes:
 Gary> I took out a wristwatch and timed it instead of guessing. I
 Gary> get three frames per second. It's about 4x from where we
 Gary> started, but still slow. I guess I'm just underpowered,
 Gary> although a couple of years ago this was a powerhouse. It
 Gary> seems that matplotlib may not be suited to this task. I
 Gary> don't think it should take 2 GHz just to power a stripchart.
One more comment here, mainly for Todd. 
Todd, I get 34 FPS on anim.py with GTKAgg and only 21 FPS with the
anim_tk.py, where both scripts are doing the same thing. The profiler
reveals a good chunk of the time is in
 103 2.300 0.022 2.300 0.022 tkagg.py:4(blit)
This may be a tk limitation, but I just wanted to point it out to you
in case there are any optimizations you can apply to that function.
I'll include the anim_tk.py I'm using for profiling below.
Cheers,
JDH
#!/usr/bin/env python2.3
import matplotlib
matplotlib.use('TkAgg')
import matplotlib.matlab
import Tkinter as Tk
import matplotlib.numerix as numerix
fig = matplotlib.matlab.figure(1)
ind = numerix.arange(60)
x_tmp=[]
for i in range(100):
 x_tmp.append(numerix.sin((ind+i)*numerix.pi/15.0))
X=numerix.array(x_tmp)
lines = matplotlib.matlab.plot(X[:,0],'o')
manager = matplotlib.matlab.get_current_fig_manager()
def updatefig(*args):
 updatefig.count += 1
 lines[0].set_ydata(X[:,updatefig.count%60])
 manager.canvas.draw()
 return updatefig.count
updatefig.count=-1
manager.show()
import time
tstart = time.time()
while 1:
 cnt = updatefig()
 if cnt==100: break
 
print 'FPS', 100.0/(time.time() - tstart)

>>>>> "Gary" == Gary Pajer <pa...@in...> writes:
 Gary> I took out a wristwatch and timed it instead of guessing. I
 Gary> get three frames per second. It's about 4x from where we
 Gary> started, but still slow. I guess I'm just underpowered,
 Gary> although a couple of years ago this was a powerhouse. It
 Gary> seems that matplotlib may not be suited to this task. I
 Gary> don't think it should take 2 GHz just to power a stripchart.
I agree. The current design of matplotlib doesn't really support this
kind of use because it redraws the entire figure every time and does
too much duplicate work at the python level. It shouldn't be too hard
to add some specialized functions for agg that support strip charts.
I've been planning to do it because we have a need for it here, and
there is some general on c.l.python for this kind of plotting feature
in python.
So I can start mulling over the design, can you tell me what kinds of
real time updates you need - only solid lines or arbitrary symbols
like 'o' too? Anything else besides line plots?
I'm envisioning some extension code that talks directly to the data
source and to the agg backend, updating only part of the canvas. The
blitting functions for GTK/WX/Tk Agg would have to be extended to blit
only a region of the canvas.
JDH

>>>>> "Gary" == Gary Pajer <pa...@in...> writes:
 Gary> It seems that I can't completely override my choice of
 Gary> backend. E.g., I have set TkAgg as my default back end.
 Gary> Yet if I modify examples/anim.py to include
 Gary> matplotlib.use('GTKAgg') or matplotlib.use('GTK') it will
 Gary> not run. A window appears, but it contains a static,
 Gary> non-changing graph. To run anim.py, I have to modify
 Gary> matplotlibrc. Same behavior the other way: with GTKAgg
 Gary> selected in matplotlibrc, I can't run Todd's anim_tk.py,
 Gary> even with TkAgg selected in the script. Am I doing
 Gary> something stupid?
It works as expected for me, both ways. I can put TkAgg in my rc and
then matplotlib.use('GTKAgg') in anim.py and it works. Ditto the
other way around. Any chance you are working in an IDE? These changes
occur at module load time, and in an IDE such as IDLE, matplotlib will
only be loaded once.
JDH

It seems that I can't completely override my choice of backend.
E.g., I have set TkAgg as my default back end. Yet if I modify
examples/anim.py to include matplotlib.use('GTKAgg') or
matplotlib.use('GTK') it will not run. A window appears, but it contains a
static, non-changing graph. To run anim.py, I have to modify matplotlibrc.
Same behavior the other way: with GTKAgg selected in matplotlibrc, I can't
run Todd's anim_tk.py, even with TkAgg selected in the script. Am I doing
something stupid?
-gary

----- Original Message ----- 
From: "John Hunter" <jdh...@ac...>
> >>>>> "Todd" == Todd Miller <jm...@st...> writes:
>
> Todd> This turned out to be really easy so now canvas.draw
> Todd> triggers a blit and functions more like the other backends.
> Todd> It's in CVS. I also found an extraneous draw() so
> Todd> performance should be better, perhaps 2x.
>
> Yep, I'm getting about 20fps on my system now. Much improved.
>
> Gary, I'm uploading a zip file which has the new matplotlib python
> code. AFAIK, all the changes were made at the python level (right
> Todd?) so you should just be able to unzip this in your site-packages
> dir to try the new code. Let me know if it works, and what kind of
> performance you are getting now.
>
> http://nitace.bsd.uchicago.edu:8080/files/share/matplotlib-0.54.1a.zip
>
> JDH
I took out a wristwatch and timed it instead of guessing. I get three
frames per second. It's about 4x from where we started, but still slow. I
guess I'm just underpowered, although a couple of years ago this was a
powerhouse. It seems that matplotlib may not be suited to this task. I
don't think it should take 2 GHz just to power a stripchart.
I've got new hardware coming this summer. I get whatever IT gives me (until
I can find funds to buy my own), so I don't know what I'll be getting.
We'll see what happens.
I have another question, but I'll start a new thread for that ...
-gary

John Hunter wrote:
>>>>>>"Peter" == Peter Groszkowski <pgr...@ge...> writes:
>>>>>>
>
> Peter> Hi: The following script:
>
> Peter> #!/usr/bin/env python from matplotlib.matlab import *
>
> Peter> figure(1) plot([0],[0]) show()
>
>Thanks, Peter, for alerting me to this problem. I'm now adding this
>script and several other instances of plotting constants in a variety
>of guises to the unit testing scripts. I think the following fix will
>work for you. Replace matplotlib.axes.Axes.add_line with
>
> def add_line(self, l):
> "Add a line to the list of plot lines"
> self._set_artist_props(l)
> 
> xdata = l.get_xdata()
> ydata = l.get_ydata()
> if l.get_transform() != self.transData:
> xys = self._get_verts_in_data_coords(
> l.get_transform(), zip(xdata, ydata))
> self.update_datalim(xys)
> else:
> # the data are already using the data coord system - no
> # transforms necessary
> minx, maxx = min(xdata), max(xdata)
> miny, maxy = min(ydata), max(ydata)
> if minx==maxx:
> minx -= 1
> maxx += 1
>
> if miny==maxy:
> miny -= 1
> maxy += 1
> 
> corners = ( (minx, miny), (maxx, maxy) )
>
> self.update_datalim(corners)
>
> l.set_clip_box(self.bbox)
> self._lines.append(l)
>
>Passes my tests...
>
>
Just a note that the version of the above method in 0.54.1 still gives me:
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 296, in draw
 self.figure.draw(self.renderer)
 File "/usr/lib/python2.2/site-packages/matplotlib/figure.py", line 
130, in draw
 for a in self.axes: a.draw(renderer)
 File "/usr/lib/python2.2/site-packages/matplotlib/axes.py", line 607, 
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 209, 
in draw
 ismath=self.is_math_text())
 File 
"/usr/lib/python2.2/site-packages/matplotlib/backends/backend_agg.py", 
line 200, in draw_text
 self._renderer.draw_text(
OverflowError: float too large to convert
When doint plot([0],[0]).
The above substitute fixes the problem though...
-- 
Peter Groszkowski Gemini Observatory
Tel: +1 808 974-2509 670 N. A'ohoku Place
Fax: +1 808 935-9235 Hilo, Hawai'i 96720, USA

A quick thank you to John,
I just wanted to confirm that 0.54.1 is behaving well on my Win98 system now and I'm looking forward to playing with line styles and more use of mathtext. The speed improvements are very noticeable too.
Thanks!
Gary Ruben 
-- 
___________________________________________________________
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm