matplotlib-devel Mailing List for matplotlib (Page 2)

Paul Barrett wrote:
> 
> Beginning yesterday afternoon, the latest version of CVS core dumps on 
> me when using the *Agg backends. The PS backend is OK. It looks like 
> the changes that were made to ft2font.cpp/h yesterday are causing the 
> problem. Any suggestions on where this bug might be occuring? I'm 
> compiling and running on RH 8.0.
False alarm. It now works - after blowing away the build tree and rebuilding 
the entire package.
-- 
Paul Barrett, PhD Space Telescope Science Institute
Phone: 410-338-4475 ESS/Science Software Branch
FAX: 410-338-4767 Baltimore, MD 21218

Beginning yesterday afternoon, the latest version of CVS core dumps on me when 
using the *Agg backends. The PS backend is OK. It looks like the changes that 
were made to ft2font.cpp/h yesterday are causing the problem. Any suggestions 
on where this bug might be occuring? I'm compiling and running on RH 8.0.
 -- Paul
-- 
Paul Barrett, PhD Space Telescope Science Institute
Phone: 410-338-4475 ESS/Science Software Branch
FAX: 410-338-4767 Baltimore, MD 21218

I've been thinking that the SciPy '04 conference 
http://www.scipy.org/wikis/scipy04/ on September 2-3 might be a good 
opportunity for some of us to meet in person and contribute to our 
favorite plotting library via a code sprint.
Unfortunately, it seems the "official" scipy code sprints have been 
canceled.
However, I'm a post-doc at Caltech, so I could organize a venue 
independent of the official conference.
So:
1) is anyone interested in participating in a matplotlib code sprint?
2) what day is best for you?
By the way, the earlybird registration date has been delayed a bit, so 
there's still time to get the reduced fee. Furthermore, there are 
apparently several more spots open for speakers, so please consider 
submitting an abstract.
Personally, I probably won't be available in the days immediately before 
the conference (Wednesday, for example), but could participate on the 
Saturday immediately after the conference. However, although I'll be 
sad to miss it, if Wednesday is best, I think I could arrange for a 
lab-mate to let participants in to the venue.
Cheers!
Andrew

I just checked (after spending all day solving network problem :-() what
effect the re-use of Agg buffer optimisation has on FltkAgg backend:
 Classic TkAgg: 9.98 FPS
 Improved TkAgg: 9.98 FPS
 classic FltkAgg: 16.1 FPS
 Improved FltkAgg: 17.2 FPS
I also installed pyGtk to be able to test the framerate I gor on may
computer:
 Classic GTKAgg: 16 FPS
 Modified GTKAgg (avoid switch backend, which make my re-use of agg
buffer impossible, use multiple inheritance instead): 16 FPS
 Improved modified GTKAgg: 16.8 FPS
And finaly, to have a complete picture, I tried Tk without blitting (as
explained in a previous message)
	classic TkAgg without blit: 14.3 FPS
	improved TkAgg without blit: 16 FPS
There is various strange things in these benchmarks: 
first I was not able to reproduce the (very small but reproductible)
advantage I observed yesterday for Agg buffer re-use optimization in the
TkAgg backend...It is observable in the FltkAgg and TkAgg backend,
though...and even more so in the TkAgg without blitting one...Maybe this
is maked by the blitting time in the normal TkAgg, though, so this does
not disturb me too much...
Next, I do not observe the high performance of the GTKAgg backend here,
on the contrary the FPS it gives me are in line with the Fltk ones, and
even with Tk when we get rid of the slow blitting...This is quite
surprising...
On the other hand, I have less trouble understanding these results than
the higher GTKAgg performance you report, so to be really complete I
tried an bare Agg rendering:
Just use the same example as my light dynamic plot (mode animation), but
with a matplotlib.use("Agg") and a 
while True: 
 updatefig()
loop instead of idle callback...
Here are the timings:
Classic Agg: 19 FPS (or, better said, RenderingPerSecond)
Optimized Agg: 20.55 RPS
So this confirm what I have observed on the various *Agg backends, which
in summary would be:
-Optimization of Agg, to reuse buffer if possible: Gain from 8% to 0%,
depending on the backend (max on Agg, small to non existent on TkAgg).
It depends also on the complexity of the rendering, the gain will be
higher when simple drawings are done, and minimal when very complex
figures are drawn...This could help for memory leak maybe, though...and
as you will see is a very minimal hack...
Performance of the various *Agg backends, using Agg as reference and a
very simple dynamic plot (for the new reuse Agg buffer scheme, current
"new Agg every draw" should be very similar):
 TkAgg: 49% (ouch!)
 TkAgg without blit: 78%
 GTKAgg: 82%
 FltkAgg: 84%
So Fltk and GTK are fast (the 20 % overhead is due to transfer to screen
buffer, double buffering, and callbacks/idle mechanisms, I guess, no way
to get better than that)
TkInter is a slower toolkit, mainly cause of blit, and also for other
reasons it seems.
Only remaining mystery (but it is a big one!) is why you observe very
different things for GTKAgg? Is it a GTK version problem? A compilation
option? This is really surprising, given the bare Agg test give me RPS
in line with my FPS...Only thing I can think of is a option during Agg
compile that decrease the performance of my Agg somehow...
 
You will find included a tar.gz of all the files I modified (including
small examples and my FltkAgg backend - even if it is not too usefull
before pyfltk has been updated)...If you need any more information or
want to discuss this, I would be glad to help :-)
PS: I forward this to matplotlib-devel, without the attachment: I do not
know if the mailinglist would accept such a thing...

The embedding of TrueType fonts in Postscript files has been add to CVS 
during the past week. This enhancement should work for both regular 
text and math text, so the text that you see on the screen should be the 
same in Postscript. This change should be transparent to all users, i.e. 
no additional font files are needed. The TTF is encoded on-the-fly and 
embedded in the PS file when it is written.
Please give it a try and let me know of any problems or anomalies.
 -- Paul
-- 
Paul Barrett, PhD Space Telescope Science Institute
Phone: 410-338-4475 ESS/Science Software Branch
FAX: 410-338-4767 Baltimore, MD 21218

>>>>> "Gregory" == Gregory Lielens <gre...@ff...> writes:
 Gregory> You are right, I should definitely install pygtk on my
 Gregory> system to check that, I wonder how a 3X increase in FPS
 Gregory> is possible: after all, de-activating blit in the TkAgg
 Gregory> produce only a 1.5X increase (and no image of course ;-)
The gtk advantage over tk depends on the example. For images (eg
for Andrew's dynamic image) the advantage is approx 1.5x. For the
simple line drawing dyanmic example you posted, it's about 3x. I
suppose the difference is that in the image example, there is a much
larger, shared computational burden in agg, whereas with the simple
line drawing example the blitting difference is more pronounced.
 Gregory> It could be more important for GTKAgg, if it is closer to
 Gregory> raw Agg speed than TkAgg and FltkAgg...Something to test
 Gregory> would be to use the Agg backend without exporting the
 Gregory> pixmap buffer but doing the drawing, and check how many
 Gregory> draw/second one can have on the examples, to really check
 Gregory> the penalty associated to the different toolkits, and the
 Gregory> maximum gain we can have by reusing Agg buffer instead of
 Gregory> creating one for each draw...Is this doable?
I'm certainly happy to try it. One last thing you may want to do
before sending in your updates tomorrow is to run backend_driver.py in
the examples subdir to make sure your changes don't create any
problems with the known examples.
 Gregory> In these cases nothing performance wise, in fact the way
 Gregory> you use should me marginally faster (avoiding the
 Gregory> creation/destruction of python buffer objects ). Python
 Gregory> buffer objects is a way for me to implement the transfer
 Gregory> without copy of the Agg buffer to fltk in more "abstract"
 Gregory> way: no need to implement a c extension that know both
 Gregory> the internals of agg and fltk, I split it using the
 Gregory> python buffer as a standard protocol (buffer objects were
 Gregory> intended for just this use, I think...). This is not
 Gregory> very important, but it could simplify things if there is
 Gregory> multiple renderer and multiple toolkits to bind...like if
 Gregory> alternative to Agg is implemented (or multiple version of
 Gregory> Agg must be supported)...and I guess that the overhead of
 Gregory> this creation/destruction of python buffer objects is
 Gregory> really negligeable.
Another area it may help is in backend_gtk and backend_wx, which *do*
use string methods to access the agg image buffer.
JDH

> > You are right, I should definitely install pygtk on my 
> system to check 
> > that, I wonder how a 3X increase in FPS is possible: after all, 
> > de-activating blit in the TkAgg produce only a 1.5X 
> increase (and no 
> > image of course ;-) ): something else than Agg must hold Tk 
> (and Fltk) 
> > back then: I have to test the FPS one have without Agg drawing and 
> > blitting, only canvas update, with GTK, Tk and Fltk, to be sure...
> > 
> I guess I'm surprised at that. How are you disabling the 
> blit? If no blit is being done, where else is the time going 
> if not for agg?
In the draw method of the FigureCanvasTkAgg class (in
matplotlib/backends/backend_tkagg.py file), I just commented out the
second line, going from:
def draw(self):
 FigureCanvasAgg.draw(self)
 tkagg.blit(self._tkphoto, self.renderer._renderer, 2)
 self._master.update_idletasks()
To:
def draw(self):
 FigureCanvasAgg.draw(self)
 #tkagg.blit(self._tkphoto, self.renderer._renderer, 2)
 self._master.update_idletasks()
This makes the image dissapear from screen of course, but still draw the
image in the in-memory Agg buffer...and ask the Tk canvas to redraw
itself (allways with the same empty image), I guess...so I indeed
suspect that the Tk canvas updating is causing the slow down somehow...I
will check that tomorrow for sure! 
Greg, puzzled too ;-)

Though I suppose it may simply be in the mechanism that
tk uses to update it's own buffer (it does its own blitting
behind the scenes as I understand it)... 

> 
> You are right, I should definitely install pygtk on my system to check
> that, I wonder how a 3X increase in FPS is possible: after all,
> de-activating blit in the TkAgg produce only a 1.5X increase (and no
> image of course ;-) ): something else than Agg must hold Tk (and Fltk)
> back then: I have to test the FPS one have without Agg drawing and
> blitting, only canvas update, with GTK, Tk and Fltk, to be sure...
> 
I guess I'm surprised at that. How are you disabling the blit?
If no blit is being done, where else is the time going if not
for agg?
Puzzled, Perry

> I didn't see where the optimization was helping - could you 
> clarify? It looks like about a 5% for tkagg and there are no 
> comparisons for the fltkagg with "classic vs optimized"
> 
> Classic TkAgg: 9.98 FPS
> Improved TkAgg: 10.6 FPS
> FltkAgg: 16.7 FPS
I will check the non optimized (ie with no reuse of Agg buffers) FltkAgg
backend tomorrow, but you are right, the improvement are reproductible
but small. The change for reusing buffer is trivial though, and it may
help if there is memory leak...
 
> As you may know, blitting in tk is pretty slow and there 
> doesn't appear to be anything we can do about it short of 
> some platform dependent extension code (which might be worth 
> doing at some point for linux and win32). With your example 
> I get approx 14 FPS with tkagg on my system and 45 FPS with 
> gtkagg. My point is that unless there are some fundamental 
> limitations in fltk as there are in tk, you might want to 
> look to gtkagg as a performance benchmark rather than tkagg. 
> gtkagg is typically 3x faster than tkagg for dynamic plots.
You are right, I should definitely install pygtk on my system to check
that, I wonder how a 3X increase in FPS is possible: after all,
de-activating blit in the TkAgg produce only a 1.5X increase (and no
image of course ;-) ): something else than Agg must hold Tk (and Fltk)
back then: I have to test the FPS one have without Agg drawing and
blitting, only canvas update, with GTK, Tk and Fltk, to be sure...
> Please send them in, either to the list or directly to Todd 
> and myself. Todd will be interested in anything pertaining 
> to tkagg.
Ok, I send the complete relevant files as attachement tomorrow, to you
and Todd.
> I understand the rational behind not creating a 
> new agg buffer object with each draw, but at the same time 
> your numbers seem to suggest that it isn't too important, 
> performance wise.
It could be more important for GTKAgg, if it is closer to raw Agg speed
than TkAgg and FltkAgg...Something to test would be to use the Agg
backend without exporting the pixmap buffer but doing the drawing, and
check how many draw/second one can have on the examples, to really check
the penalty associated to the different toolkits, and the maximum gain
we can have by reusing Agg buffer instead of creating one for each
draw...Is this doable?
> Also, I am not sure about the necessity of 
> creating a python buffer object - perhaps you can explain 
> this a bit more. tkagg and gtkagg both use the agg rendering 
> buffer directly with no string copy, eg
> 
> RendererAgg* aggRenderer = static_cast<RendererAgg*>(args[1].ptr());
> 
> 
> 
> //gtk
> 
> gdk_draw_rgb_32_image(drawable, gc, 0, 0, 
> 			 width, 
> 			 height, 
> 			 GDK_RGB_DITHER_NORMAL,
> 			 aggRenderer->pixBuffer,
> 			 width*4);
> // tk
> block.pixelPtr = aggRenderer->pixBuffer;
> 
> where pixBuffer is the agg pixel buffer.
> 
> What does exposing the buffer in the python layer buy you?
In these cases nothing performance wise, in fact the way you use should
me marginally faster (avoiding the creation/destruction of python buffer
objects ). 
Python buffer objects is a way for me to implement the transfer without
copy of the Agg buffer to fltk in more "abstract" way: no need to
implement a c extension that know both the internals of agg and fltk, I
split it using the python buffer as a standard protocol (buffer objects
were intended for just this use, I think...). 
This is not very important, but it could simplify things if there is
multiple renderer and multiple toolkits to bind...like if alternative to
Agg is implemented (or multiple version of Agg must be supported)...and
I guess that the overhead of this creation/destruction of python buffer
objects is really negligeable.
Best regards,
Greg.

>>>>> "Gregory" == Gregory Lielens <gre...@ff...> writes:
 Gregory> So it seems my optimisation has an impact, although
 Gregory> moderate... On the other hand, the copy mechanism induce
 Gregory> some lag in the TkAgg backend, while reusing the buffer
 Gregory> in FltkAgg seems a nice improvement...To check that, I
 Gregory> disabled the copy in the TkAgg (tkagg.blit call), and got
 Gregory> 16.4 FPS). I think thus my FltkAgg backend has the same
 Gregory> speed as bare Agg, while some optim are maybe possible on
 Gregory> TkAgg (if Tk can reuse an extern buffer, I am a complete
 Gregory> beginner in Tk so maybe my conclusion are invalid, if
 Gregory> there is a flaw in my examples...
I didn't see where the optimization was helping - could you clarify?
It looks like about a 5% for tkagg and there are no comparisons for
the fltkagg with "classic vs optimized"
 Classic TkAgg: 9.98 FPS
 Improved TkAgg: 10.6 FPS
 FltkAgg: 16.7 FPS
As you may know, blitting in tk is pretty slow and there doesn't
appear to be anything we can do about it short of some platform
dependent extension code (which might be worth doing at some point for
linux and win32). With your example I get approx 14 FPS with tkagg on
my system and 45 FPS with gtkagg. My point is that unless there are
some fundamental limitations in fltk as there are in tk, you might
want to look to gtkagg as a performance benchmark rather than tkagg.
gtkagg is typically 3x faster than tkagg for dynamic plots.
 Gregory> Depending on what you think of that, I can submit patches
 Gregory> for the Agg optimisation, exposing the Agg buffer as a
 Gregory> python buffer object (allowing buffer sharing instead of
 Gregory> buffer copying, if toolkit support this). For the fltk
 Gregory> backend, I am ready to support it but it should wait
 Gregory> acceptance of some modif I made in the python bindings of
 Gregory> fltk, for now it does not work with stock pyfltk
 Gregory> bindings...
Please send them in, either to the list or directly to Todd and
myself. Todd will be interested in anything pertaining to tkagg. I
understand the rational behind not creating a new agg buffer object
with each draw, but at the same time your numbers seem to suggest that
it isn't too important, performance wise. Also, I am not sure about
the necessity of creating a python buffer object - perhaps you can
explain this a bit more. tkagg and gtkagg both use the agg rendering
buffer directly with no string copy, eg
 RendererAgg* aggRenderer = static_cast<RendererAgg*>(args[1].ptr());
//gtk
 gdk_draw_rgb_32_image(drawable, gc, 0, 0, 
			 width, 
			 height, 
			 GDK_RGB_DITHER_NORMAL,
			 aggRenderer->pixBuffer,
			 width*4);
// tk
 block.pixelPtr = aggRenderer->pixBuffer;
where pixBuffer is the agg pixel buffer.
What does exposing the buffer in the python layer buy you?
It is best (for me) for you to submit your changes as complete files
so I can merge / compare with ediff; my dev tree is often out of sync
with the non-devel cvs tree so applying diffs is hard.
Thanks!
JDH

Oups- forgot to include the "light" dynamic example:
#!/usr/bin/env python
"""
An animated image
"""
import sys, time, os, gc
from matplotlib import rcParams
import matplotlib
matplotlib.use("TkAgg")
from matplotlib.matlab import *
import Tkinter as Tk
fig = figure(1)
a = subplot(111)
a = arange(121.0)*2*pi/120.0
dR = 0.1*sin(5*a)
x_0=sin(a)
y_0=cos(a)
line = plot(x_0,y_0)
axis([ -1.5,1.5, -1.5, 1.5 ])
manager = get_current_fig_manager()
cnt = 0
tstart = time.time()
t=0
class loop:
 
 def __init__(self, master):
 self.master = master
 self.updatefig() # start updating
 
 def updatefig(self):
 global t,x_0,y_0, dR, cnt, start,tstart
 t += pi/20
 R=1+sin(t)*dR
 line[0].set_data(R*x_0,R*y_0)
 manager.canvas.draw()
 cnt += 1
 if not cnt%100:
 print 'FPS', 100.0/(time.time() - tstart)
 tstart=time.time()
 self.master.after(1, self.updatefig) 
cnt = 0
loop(manager.canvas._tkcanvas)
show()

John Hunter wrote:
> > My best guess: your numerix settings don't agree. This will 
> cause very 
> > poor performance, since the extension code has to fall back on the 
> > python sequence API (is this actually the correct 
> explanation of why 
> > it's slow, Todd?)
Todd Miller wrote: 
> I believe that's correct. If matplotlib is compiled against 
> Numeric, the array API calls don't see arrays, they see 
> sequences (numarrays) which must be converted into (Numeric) 
> arrays. This adds both constructor overhead and sequence 
> protocol overhead (almost certainly the dominant factor for 
> all array sizes).
Thanks a lot, I think it was that indeed! My fault for not reading the
FAQ!
Now I got around a 5 time increase in FPS, not the 10 FPS you have on
your computer but not too bad... :-)
I have redone my timings:
Classic TkAgg: 4.99 FPS
"Improved" TkAgg with no Agg realloc when h,w, DPI is constant: 5.18 FPS
FltkAgg (same as improved TkAgg, but use a new Agg tobuffer_rgba method
to reuse the Agg buffer instead of copying it: this is possible using
the fltk toolkit): 6.3 FPS
I still mainly measure the Agg drawing performance, so I did a new test
to check with a lighter drawing (included below, an annular mode (order
5) animation...)
Here are the timings for thoses:
Classic TkAgg: 9.98 FPS
Improved TkAgg: 10.6 FPS
FltkAgg: 16.7 FPS
These timings are with figures of the same size (it has an influence on
the FPS of course)
So it seems my optimisation has an impact, although moderate...
On the other hand, the copy mechanism induce some lag in the TkAgg
backend, while reusing the buffer in FltkAgg seems a nice
improvement...To check that, I disabled the copy in the TkAgg
(tkagg.blit call), and got 16.4 FPS).
I think thus my FltkAgg backend has the same speed as bare Agg, while
some optim are maybe possible on TkAgg (if Tk can reuse an extern
buffer, I am a complete beginner in Tk so maybe my conclusion are
invalid, if there is a flaw in my examples...
Depending on what you think of that, I can submit patches for the Agg
optimisation, exposing the Agg buffer as a python buffer object
(allowing buffer sharing instead of buffer copying, if toolkit support
this). For the fltk backend, I am ready to support it but it should wait
acceptance of some modif I made in the python bindings of fltk, for now
it does not work with stock pyfltk bindings... 
Best Regards,
Greg.

On Thu, 2004年07月15日 at 10:25, John Hunter wrote:
> >>>>> "Gregory" == Gregory Lielens <gre...@ff...> writes:
> 
> Gregory> It seems thus that Agg drawing is the main limiting
> Gregory> factor here, all the tricks to avoid using strings (or
> Gregory> reallocating Agg renderer, for that matter) are not too
> Gregory> usefull... What I do not understand is why I got such
> Gregory> low values, compared to the 4 or 10 FPS: I guess, given
> Gregory> the impact of Agg drawing, all the *Agg backends should
> Gregory> have about the same speed...Is there something I miss
> Gregory> here? My workstation is not current top of class, but
> Gregory> it's a PIV 2.3 GHz, so certainly not slow either...I do
> Gregory> not think the graphic subsystem is at fault, cause except
> Gregory> for a mistake of my part, blit only test shows that Agg
> Gregory> is really the origin of the poor FPS...
> 
> My best guess: your numerix settings don't agree. This will cause very
> poor performance, since the extension code has to fall back on the
> python sequence API (is this actually the correct explanation of why
> it's slow, Todd?)
I believe that's correct. If matplotlib is compiled against Numeric,
the array API calls don't see arrays, they see sequences (numarrays)
which must be converted into (Numeric) arrays. This adds both
constructor overhead and sequence protocol overhead (almost certainly
the dominant factor for all array sizes).
Regards,
Todd

>>>>> "Gregory" == Gregory Lielens <gre...@ff...> writes:
 Gregory> It seems thus that Agg drawing is the main limiting
 Gregory> factor here, all the tricks to avoid using strings (or
 Gregory> reallocating Agg renderer, for that matter) are not too
 Gregory> usefull... What I do not understand is why I got such
 Gregory> low values, compared to the 4 or 10 FPS: I guess, given
 Gregory> the impact of Agg drawing, all the *Agg backends should
 Gregory> have about the same speed...Is there something I miss
 Gregory> here? My workstation is not current top of class, but
 Gregory> it's a PIV 2.3 GHz, so certainly not slow either...I do
 Gregory> not think the graphic subsystem is at fault, cause except
 Gregory> for a mistake of my part, blit only test shows that Agg
 Gregory> is really the origin of the poor FPS...
My best guess: your numerix settings don't agree. This will cause very
poor performance, since the extension code has to fall back on the
python sequence API (is this actually the correct explanation of why
it's slow, Todd?)
 http://matplotlib.sourceforge.net/faq.html#SLOW
To make sure, rm -rf the matplotlib build dir and the
site-packages/matplotlib install dir and rebuild with NUMERIX =
'numarray' in setup.py, and make sure numerix is set to numarray in
your rc file.
I get 10FPS on the example you posted (3.4GHz P4). It's a faster
machine than yours, but it's not 10 times faster. If I use numarray
in my rc file and build with Numeric, I get 1.6FPS.
JDH 

Hi, 
I try to benchmark some modif I did to speed up Agg rendering
(basically, avoid re-creation of an Agg renderer if draw is called
without changing previous fig size and DPI)...
To do so, I changed the dynamic_image demo to use TkAgg (except my fltk
backend, it's the only one working on my workstation for the moment, I
do not have Wx not GTK).
First tests shows no improvement :-(, but in fact I can not reproduce
the speed mentioned when you discussed this demo (4 FPS or 10 FPS), only
got 0.9 FPS.
I thus tryed to check why I got such slow animation, and the results are
as follow (I use the current CVS matplotlib, with numarray):
 Example with no drawing (manager.canvas.draw commented out in the
updatefig method) : stabilize around 50 FPS, this is the best we can
hope using numarray which is, I think, the only limitting factor in this
case)...
 Example with call to tkagg.blit but no Agg canvas drawing (done
replacing the draw method in FigureCanvasTkAgg, see below * ): stabilize
around 19 FPS
 * old draw:
 def draw(self): 
 FigureCanvasAgg.draw(self)
 tkagg.blit(self._tkphoto,self.renderer._renderer, 2)
 self._master.update_idletasks()
 new version:
 def draw(self): 
 try: 
	 tkagg.blit(self._tkphoto,self.renderer._renderer, 2)
 except:
 FigureCanvasAgg.draw(self)
 tkagg.blit(self._tkphoto,self.renderer._renderer, 2)
 self._master.update_idletasks()
 
 Example with Agg canvas drawing + blitting: (normal TkAgg backend):
 stabilize around 1 FPS
 It seems thus that Agg drawing is the main limiting factor here, all
the tricks to avoid using strings (or reallocating Agg renderer, for
that matter) are not too usefull...
What I do not understand is why I got such low values, compared to the 4
or 10 FPS: I guess, given the impact of Agg drawing, all the *Agg
backends should have about the same speed...Is there something I miss
here?
My workstation is not current top of class, but it's a PIV 2.3 GHz, so
certainly not slow either...I do not think the graphic subsystem is at
fault, cause except for a mistake of my part, blit only test shows that
Agg is really the origin of the poor FPS...
Any idea about this? 
Thanks,
Best regards,
Greg.
----
Dynamic_image_tkagg.py
----
#!/usr/bin/env python
"""
An animated image
"""
import sys, time, os, gc
from matplotlib import rcParams
import matplotlib
matplotlib.use("TkAgg")
from matplotlib.matlab import *
import Tkinter as Tk
fig = figure(1)
a = subplot(111)
x = arange(120.0)*2*pi/120.0
x = resize(x, (100,120))
y = arange(100.0)*2*pi/100.0
y = resize(y, (120,100))
y = transpose(y)
z = sin(x) + cos(y)
im = a.imshow( z, cmap=cm.jet)#, interpolation='nearest')
manager = get_current_fig_manager()
cnt = 0
tstart = time.time()
class loop:
 
 def __init__(self, master):
 self.master = master
 self.updatefig() # start updating
 
 def updatefig(self):
 global x, y, cnt, start
 x += pi/15
 y += pi/20
 z = sin(x) + cos(y)
 im.set_array(z)
 manager.canvas.draw()
 cnt += 1
 if not cnt%20:
 print 'FPS', cnt/(time.time() - tstart)
 self.master.after(1, self.updatefig) 
cnt = 0
loop(manager.canvas._tkcanvas)
show()

> Hi Gregory,
> 
> Yes, this is a simple oversight. In the autoscale method of
> LogLocator, return
> 
> return self.nonsingular(vmin, vmax)
Great! I will try this one! Or maybe you have already added it in the
CVS?
> A number of users have requested
> support for plotting arrays with NaN (this might be 
> considered a special case) but this is made a but difficult 
> since python doesn't support nan across platforms and numeric 
> and numarray handle this differently. Not impossible, of 
> course, just difficult. 
In fact I though about requesting that also ;-), but it seems indeed
related to numarray/Numeric behavior: The utility of this feature in
Matplotlib would be highly dependent to the way the array package deal
with math errors/NaN: 
A quick test shows me that numarray warn and put NaN where elements are
outside of the math domain when using ufunc on arrays.
Numeric produce a ValueError: math domain error, 
and matlab silently promote real matrices o complex ones when possible,
and put NaN when it's not to obtain the result... 
Well, I personally think the numarray way is the sanest and most
usefull...but for now you are right, this will be a nightmare to deal
with, at least if there is no way to make Numeric behaves like
Numarray.... On the other hand, Numeric should be replaced in the future
by numarray, but I guess the problem is: it will probably not be the
near future...:-( 
Regarding NaN python support across platform, do you know across on
which platform it is not supported? "Exotic" ones? This is of particular
interest to me (and my company), as a platform which does not support
NaN within python would probably be very annoying for porting our softs,
and our targets are commercial flavor of unix, linux and win32...I hope
the problem arise only on non IEEE754 compliant platforms? 
> Special casing this for log would be
> considerably easier.
 Yes, probably a y->max(DBL_EPSILON,y), and modifying the autoscale
method to avoid "extreme" values when computing the bounding box of the
figure...
> I plan on redoing the entire navigation scheme in the near
> future. It will provide
> 
> * "hand" pan whether than button click. Ie, you select a hand tool
> and physically move the axis. The axes select menu for multiple
> axes would probably be replaced by a "apply to all" checkbox. Ie,
> your navigation would affect one or all of the axes
> 
> * zoom to rectangle
> 
> * a view limit stack with forward and back buttons like on a web
> browser to navigate through previously defined views.
> 
> When this is done, I plan on making the toolbar an rc param
> (classic or newfangled or none). 
Great ideas, I though about something like these too, but didn't though
about the stack with forward and backward button :-)
I would keep the axis per axis selection with select all and invert all,
though, this offer better flexibility :-)
Other possibilities that crossed my mind are a zoom out mirroring the
zoom in to rectangle: the zoom out would be so that the current figure
would fit in the rectangle selected by the user...this is the exact
reverse of zoom to rectangle, but need some test to see if it is
intuitive to use...
And also a single click zoom in/zoom out (by a factor of 1.5 or tunable
for example, centered on the mouse (either click + [+] or [-] to zoom
in/ zoom out, or wheelmouse zooming in/out relative to the current
position of the pointer)...I'll wait your prototype in a backend before
implementing those then, so that I can see which ideas get retained :-)
 
, So it would be ideal if you 
> implemented a classic toolbar for your backend before a 
> newfangled one, but is not a requirement.
This is done already, I tried to reproduce as well as possible the TkAgg
backend...(a nice way to say the FltkAgg is a complete shamefull ripoff
of TkAgg...)
> Because you opted to make a *Agg backend, this task is vastly
> simplified since Agg automatically will implement all the new 
> drawing features for you, ie images, mathtext, fonts and 
> other hard things come for free. But there will still be 
> fltk version, platform and installation issues that arise.
> If you're willing to make this ongoing commitment, my answer
> still is definitely! If this looks like too much to you, 
> I'll be happy to include links to it on my site but may not 
> want to make it part of the official distribution.
> 
> Sound fair?
Yes, of course, completely, I agree this is an issue...Maintenance
should be limited because fltk/pyfltk is quite a simple toolkit, and not
a very fast moving target (for the best and the worst ;-) ), and anyway
as you said it is a quite simple stuff cause once the basic method for
introducing Agg in-memory image into an Ftlk widget, the rest is quite
simple widget programing (I have done that in order to learn about fltk,
and because it was fun :-) )
As my backend is quite similar to the TkAgg one, I am quite confident I
would be able to mirror the changes of TkAgg quite easily...but it is
nonetheless an effort, especially for documentation...I will discuss
that with other guys in the company, this will depends if we decide to
use matplotlib in some utilities from now on...The platform we use are
commercial unixes, linux and windows, and these last 2 are an absolute
requirement so porting and test will be done anyway for those. OS X,
well, we don't have any for now but it could change...
In the meantime, I would like to submit some patches to the Agg backend,
something I have done to avoid the string copy and re-allocation of the
Agg buffer each time one draw (basically, expose the image buffer as a
python buffer object, and reallocate a new Agg renderer only if h,w or
dpi change, just erase it on draw when those stay constants...I guess
this could improve the TkAgg and GtkAgg backends too, I need to check if
I can change those easily to use the buffer...Does these
changes/additions to the Agg renderer seems OK to you? If yes, adding
the fltk backend will be trivial for any user having fltk/pyfltk
installed...How do you prefer patches, as diff? Or complete modified
file?
Best regards,
Greg.
PS: Sorry if the message is not send to matplotlib-devel list, it seems
my mails are rejected by the sourceforge server...Do you have added some
restriction to the devel list? If not, maybe I have beend blacklisted, I
should check if I am not relaying spam...:-(

Jared has gotten a nice start on an SVG backend, but there are a few
more things that need to be done and other work has overtaken him.
There has been a lot of interest in an SVG backend, generally, and
Eric and Paul have both expressed some interest in the past in
developing this backend, so I thought I could corral some of that
interest into finishing it off.
Here are the areas I'm aware of
 * font support - currently font support in svg is broken. This is a
 natural one for you Paul, if you still have any hair left after the
 cmex fonts in ps mathtext.
 * mathtext support - shouldn't be too bad after fixing above for
 truetype fonts. Probably involves some issues of how to get svg
 renderers to handle unknown fonts (cm*). Paul?
 * image support - Jared and I discussed this earlier and SVG
 apparently doesn't handle bitmaps as direct includes. So we can't
 use the same trick that worked for PS. But you can include PNG
 files by filename. I just added a "write_png" method to the _image
 module, and implemented a stub draw_image in backend svg that calls
 this method. What's left is to handle the offsets and generate the
 appropriate svg. Eric?
 * numarray broken - for reasons not clear to me I get a "ValueError:
 function not supported' error on the SVG backend on the call to
 y = self.height - y
 in draw_lines running with rc numarray and a matplotlib compiled
 with numerix. Haven't had time to debug this further.
 * is there a figure centering issue in svg as their is in ps, so that
 the image appears in the center of the page, when, for example,
 loaded into a web browser with the svg plugin? 
 * docs - document the backend in backends.html.template, links to svg
 viewers, etc...
 * dpi - is SVG properly setup to ignore dpi calls?
Jared, I had already made some changes to the backend before the diff
you sent me with your latest version so I can't merge. If you could
resend a complete file, I can manually merge with ediff.
Ideally, Paul could fixup the text related stuff since he already has
a lot of expertise there and Eric could take the rest. Let me know...
Thanks!
JDH

>>>>> "Gregory" == Gregory Lielens <gre...@ff...> writes:
 Gregory> Hi, I just encounter a problem of robustness when using
 Gregory> semilogy: when all the y data are the same, I got a
 Gregory> ZeroDivisionError: SeparableTransformation:eval_scalars
 Gregory> yin interval is zero; cannot transform
 Gregory> A classic plot have no problem and draw a flat line with
 Gregory> conventional y interval (range 0-2 for y=1).
 Gregory> Minimal example:
 Gregory> from matplotlib.matlab import all x=arange(10) y=0*x+1
 Gregory> plot(x,y) -> ok figure(2) semilogy(x,y) -> error
 Gregory> I guess the special-casing done for plot was not extended
 Gregory> to semilog?
Hi Gregory,
Yes, this is a simple oversight. In the autoscale method of
LogLocator, return
 return self.nonsingular(vmin, vmax)
 
 Gregory> On a related matter (and probably far more difficult to
 Gregory> change), for now if one plot y values having 0 or
 Gregory> negative elements, one got a math error, while in matlab
 Gregory> negative values are ignored...would it be possible to
 Gregory> switch (ideally, optionally with the help of a command or
 Gregory> option in .matplotlibrc) to matlab behavior? I guess
 Gregory> doing a max(epsilon, y) on the data which would be
 Gregory> logarithmically scaled, and not taking into account data
 Gregory> below a certain value (mindouble?) for computing the y
 Gregory> range would do it...
Yes, this is a much more difficult issue. It used to be more
difficult in earlier versions of matplotlib when x and y transforms
were handled independently. Now that transforms of x and y happen
together in the new transform architecture, it should be possible. A
number of users have requested support for plotting arrays with NaN
(this might be considered a special case) but this is made a but
difficult since python doesn't support nan across platforms and
numeric and numarray handle this differently. Not impossible, of
course, just difficult. Special casing this for log would be
considerably easier.
 Gregory> Finally, I am planning to submit a new backend (fltkAgg),
 Gregory> builded on the model of tkagg ang gtkagg but using fltk
 Gregory> and it's pyfltk bindings...is this of interest? It is
 Gregory> almost ready, but I had to modify pyfltk so i prefer to
 Gregory> wait till my modifs are accepted on this side (and also
 Gregory> want to experiment with a matlab-like interractive zoom,
 Gregory> is there something similar present in other interractive
 Gregory> backends?)
I plan on redoing the entire navigation scheme in the near future. It
will provide
 * "hand" pan whether than button click. Ie, you select a hand tool
 and physically move the axis. The axes select menu for multiple
 axes would probably be replaced by a "apply to all" checkbox. Ie,
 your navigation would affect one or all of the axes
 * zoom to rectangle
 * a view limit stack with forward and back buttons like on a web
 browser to navigate through previously defined views.
When this is done, I plan on making the toolbar an rc param (classic
or newfangled or none). So it would be ideal if you implemented a
classic toolbar for your backend before a newfangled one, but is not a
requirement.
As for including new backends in matplotlib. My initial response was
definitely! My new response is definitely, with caveats. Maintaining
the various backends across operating systems has become a challenge.
Eg, 6 backends cross 3 major platforms is 18 combinations, this is
compounded by the fact that most of the GUIs we support have different
versions in play. That says nothing about developing new features,
maintaining the front end, documentation, web page, etc -.
Historically, backend developers have implemented the features they
want and need and don't expend a lot of effort keeping their backend
current with new features, implementing a full feature set, testing
across various operating systems, maintaining web documentation for
installing and using the backend (in backends.html) and answering
mailing list questions specific to your backend. For example, the wx
implementer has done very little since the first, admittedly nice, wx
implementation. Because I care about distributing a product that
works, it usually falls upon me to do it and I don't have any more
free time. A more recent example is the submission of the SVG
backend, which is also in need of a new maintainer. Todd Miller, who
wrote the Tk backend, has been a notable and much welcomed exception.
Because you opted to make a *Agg backend, this task is vastly
simplified since Agg automatically will implement all the new drawing
features for you, ie images, mathtext, fonts and other hard things
come for free. But there will still be fltk version, platform and
installation issues that arise.
If you're willing to make this ongoing commitment, my answer still is
definitely! If this looks like too much to you, I'll be happy to
include links to it on my site but may not want to make it part of the
official distribution.
Sound fair?
JDH
 

For a start, you can replace 'PS' with 'SVG' in pstest.py in the
examples. Otherwise, any of the examples that don't have mathtext or
images should work. Just add
import matplotlib
matplotlib.use('SVG')
at the beginning and then
savefig('myfilename')
at the end.
jared
On Fri, 2004年07月09日 at 06:59, Flavio Codeco Coelho wrote:
> So...
>=20
> can we type=20
>=20
> matplotlib.use('SVG')=20
>=20
> and start playing with it or what?
>=20
> what about some examples?;)
>=20
>=20
>=20
>=20
> Fl=C3=A1vio Code=C3=A7o Coelho,
> PhD
>=20
> Programa de Computa=C3=A7=C3=A3o
> Cient=C3=ADfica
>=20
> Funda=C3=A7=C3=A3o Oswaldo Cruz
>=20
> Rio de Janeiro --
> Brasil
>=20
>=20
>=20
>=20
>=20
>=20
> ______________________________________________________________________

What's new in matplotlib-0.60.1
 * figure images (pixel-by-pixel, not resampled) with the figimage
 command. Multiple figure images (ie mosaics) with alpha blending
 are supported. See
 http://matplotlib.sf.net/examples/figimage_demo.py
 * multiple axes images with imshow using alpha blending. See
 http://matplotlib.sf.net/screenshots.html#layer_images
 * unified color limit and color mapping arguments to pcolor, scatter,
 imshow and figimage. Interactive control of colormap and color
 scaling with new matplotlib.matlab commands jet, gray and clim.
 New matplotlib rc parameters for default image params. image
 origin can be upper or lower - see
 http://matplotlib.sf.net/examples/image_origin.py
 * colorbar -
 http://matplotlib.sf.net/matplotlib.matlab.html#-colorbar - now
 works with imshow, pcolor, and scatter
 * new 'draw' command to redraw the figure - use this in place of
 multiple calls to show. This is equivalent to doing
 get_current_fig_manager().canvas.draw(), but takes less typing :-)
 * support for py2exe - see
 http://matplotlib.sf.net/py2exe_examples.zip
 * New finance demo shows off many of the features of matplotlib - see
 screenshot at
 http://matplotlib.sf.net/screenshots.html#finance_work2
 * new matplotlib.matlab command 'rc' for dynamic control of rc
 parameters. See
 http://matplotlib.sf.net/matplotlib.matlab.html#-rc and example
 http://matplotlib.sf.net/examples/customize_rc.py
 * Andrew Straw submitted a dynamic_image example. The wx version is
 still in progress and has some flicker problems, but the gtk version
 is pretty cool - 
 http://matplotlib.sf.net/examples/dynamic_image_gtkagg.py
 * Bug fixes: dynamic_demo_wx, figure legends, memory leaks, axis
 scaling bug related to singleton plots, mathtext bug for '6', some
 numarray bug workarounds
See http://matplotlib.sf.net/CHANGELOG for details
Downloads at http://sourceforge.net/projects/matplotlib
Enjoy!
JDH

Hello again,
Just to clean up my mess, I've sent John a couple of patches, one which
cleans up the SVG backend a little, and the other which makes it so that
print_figure() (at least in the agg backends) will save as SVG when the
filename ends in .svg.
A couple other features I had been thinking about, but won't have time
to work on:
-Compressed (gzipped) SVG
-Using <marker> elements for symbols. This would shrink file sizes a
lot. You could create a Polygon collection renderer for this I think,
but it may be more involved...
Also, using python's built-in DOM implementation might result in cleaner
code, but may not be worth it.
Now, I'd better go do some physics before my adviser finds out what I've
been doing with my time... ;)
jared

Hi,
Anyone is welcome to work on the SVG backend. I didn't realize that
John thought I was hard at work on improving it, when actually I've been
happily using it. Sorry for not communicating that... I'm not going to
have any time to work on it in the near future, so go nuts. I'm an
amateur, so there are plenty of bugs! :)
On Thu, 2004年07月08日 at 16:16, John Hunter wrote:
> There is an SVG backend already in matplotlib. It hasn't been
> announced because it is in development by Jared Wahlstrand. Perhaps
> Jared can give a status report on what needs to be done, and you might
> want to help out. He might have a more recent copy in his development
> tree than I do.
> 
> Here are the issues as I understand them:
> 
> * image support
This is waiting on a save_image function in the Agg backend, so that we
can link to an external PNG file.
> * font support (freetype vs afm), use of font families /
> font_manager
Is this the issue of 'helvetica' versus 'sans serif'?
> * mathtext
I don't know where to begin here, but the implementation is going to
look a lot like the PS backend. It would be cool to embed MathML, but
good luck finding a viewer capable of reading it... :)
> * some oddness when the user calls savefig with a high dpi?
> Shouldn't SVG ignore the dpi setting? That's what I did in
> backend_ps.
You're right, it shouldn't need to know the dpi. This is an artifact
from when I ported everything from the PS backend.
> * There also appears to be some problem in centering the figure?
I haven't experienced this.
I've been using it to export to inkscape to make figures for papers and
conference talks and haven't had any major problems. The code in 0.60
is the same as I've been using, with the exception of adding another
case to print_figure() to switch to the SVG backend when the filename
has a .svg extension.
It's not complicated code, so it should be easy to understand, but let
me know if you have any questions.
Cheers,
Jared

Typo:
->to the fig.legend placement. I had to problem placing the axes.
should have read: I had _no_ problem placing the axes
sorry,
Jim

Hi,
 As you know in matplotlib 0.60 fig.legend does allow
placing the legend outside of the axis. I'm hoping to find its
position, and then position the axes where i want wrt
to the fig.legend placement. I had to problem placing the axes.
For the legend i tried
rec = legendInstance.get_frame()
lVertices = rec.get_verts() 
I think that the lVertices don't truly represent where the
legend actually gets placed. e.g. putting the legend at the upper left
or lower right don't change the values in lVertices.
I guess what i'm really trying to accomplish is a legend placement
along the lines of something like 
'outside upper left' --> meaning outside of the axes to the upper left
'outside lower left' --> meaning outside of the axes to the lower left 
etc.
I think i can do this at my application level...if i can either get the
legend placement, or set the position. Another approach would be
to attempt to hack up the legend.py code to accept other placements.
Am i making this way more complicated than it is?
Any suggestions?
Thanks,
Jim