matplotlib-devel Mailing List for matplotlib (Page 543)

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

Quoting John Hunter <jdh...@ni...>:
> Perhaps Fernando or some other knowledgeable wx person can comment on
> the appropriate workaround if there is one.
Currently my workaround is to use Tk :(
Cheers,
f

What I was trying to say is that insofar as the SVG backend is a work in progress, the PyChart backend could be used an example to aid development. Just trying to be helpful :)
Chris

>>>>> "cfuller" == cfuller <cf...@th...> writes:
 cfuller> A nice source for some SVG inspiration might be PyChart,
 cfuller> another python plotting system, that has a fully
 cfuller> functional SVG backend:
 cfuller> http://www.hpl.hp.com/personal/Yasushi_Saito/pychart. I
 cfuller> like the looks/features of this package, but it lacks
 cfuller> interactivity/GUI support and relies on ghostscript for
 cfuller> rendering images.
Are you aware that matplotlib has an SVG backend already? Jared
Wahlstrand submitted one back in late May, which I haven't announced
yet. Jared what is the status on backend_svg
 - font support?
 - mathtext support?
 - image support?
JDH

>>>>> "cfuller" == cfuller <cf...@th...> writes:
 cfuller> wx won't start up on my linux machine, running Fedora
 cfuller> Core 2 and a compiled-from-source wxPython 2.5.1. There
 cfuller> was some incompatability with the new GTK libraries,
 cfuller> since the wxPython rpm was comppiled on RH9. I'm guessing
 cfuller> the wx backend is having similar troubles, although I
 cfuller> compiled it from source, naturally. That's a long
 cfuller> compile, BTW! The wx backend works for me at work, under
 cfuller> Server 2003 and the same version of wx. It still leaks,
 cfuller> although I upgraded to the .60b installation binary from
 cfuller> John's website. Compiling distutil packages under windows
 cfuller> is something I've yet to master, whether with the Borland
 cfuller> compiler or the (not so new) Visual C++ Tooolkit
 cfuller> 2003. Visual Studio just isn't something I can justify,
 cfuller> even if the lab would pay for it. Especially with the VC6
 cfuller> vs VC7 funny business. At least Tk stopped leaking!
Could you send me the script that is leaking?
 cfuller> Since I have a wx that works, its not so bad. I'll still
 cfuller> work on the FC2 issues, but I can see about that toolbar
 cfuller> addition as well. I should get around to installing
 cfuller> windows again at home, I've been putting off an upgrade
 cfuller> to XP, and my old win2k pro install is useless, after a
 cfuller> mobo upgrade.
I believe this is the bug Fernando Perez was writing about which is
specific to recent releases of wx that use private GTK symbols that
are no longer present in the gtk libs in Fedora core 2. Here is a
snip from an email he sent me earlier on the subject. As far as I
know, there is nothing we can do about it on the matplotlib side,
except perhaps check the wx/wxpython list to see if it has been fixed
yet in CVS, and agitate for a fix if not. 
Perhaps Fernando or some other knowledgeable wx person can comment on
the appropriate workaround if there is one.
From: Fernando Perez <Fer...@co...>
Subject: Re: matplotlib, ipython and other comments
To: John Hunter <jdh...@ni...>
Date: 2004年6月09日 14:29:54 -0600
Organization: Applied Mathematics, University of Colorado at Boulder
...snip ...
> I'll look into this later. My experience with WX and WXAgg is that
> both work under linux, but WX is a bit slow and buggy. Is the problem
> you are describing Fedora specific? (Sorry I can't easily read these
> links now since URL cut-and-paste from my xterm on OSX laptop to my
> browser window doesn't work).
No, the bug is in current WX. Here's a traceback:
In [6]: import wx
---------------------------------------------------------------------------
ImportError Traceback (most recent call last)
/home/fperez/<console>
/usr/lib/python2.3/site-packages/wx/__init__.py
 43 __revision__ = "$Revision: 1.1.2.4 $"[11:-2]
 44
---> 45 from wxPython import wx
 46
 47 _newnames = {}
/usr/lib/python2.3/site-packages/wxPython/__init__.py
 18 # Ensure the main extension module is loaded, in case the add-on modules
 19 # (such as utils,) are used standalone.
---> 20 import wxc
 21
 22 
#----------------------------------------------------------------------------
ImportError: /usr/lib/libwx_gtk2-2.4.so.0: undefined symbol: 
_gtk_accel_group_detach
Apparently the WX guys chose to use _gtk_* symbols which the GTK documentation 
_explicitly warned_ were private and could go away at any time. Now, in the 
version of GTK shipped with Fedora they _did_ go away, so Wx broke. This just 
needs to be fixed by the Wx team (maybe it already is in CVS, I'm using Wx as 
shipped with Fedora). So don't worry about this, it will get fixed in time by 
those responsible.

wx won't start up on my linux machine, running Fedora Core 2 and a compiled-from-source wxPython 2.5.1. There was some incompatability with the new GTK libraries, since the wxPython rpm was comppiled on RH9. I'm guessing the wx backend is having similar troubles, although I compiled it from source, naturally. That's a long compile, BTW!
The wx backend works for me at work, under Server 2003 and the same version of wx. It still leaks, although I upgraded to the .60b installation binary from John's website. Compiling distutil packages under windows is something I've yet to master, whether with the Borland compiler or the (not so new) Visual C++ Tooolkit 2003. Visual Studio just isn't something I can justify, even if the lab would pay for it. Especially with the VC6 vs VC7 funny business. At least Tk stopped leaking!
Since I have a wx that works, its not so bad. I'll still work on the FC2 issues, but I can see about that toolbar addition as well. I should get around to installing windows again at home, I've been putting off an upgrade to XP, and my old win2k pro install is useless, after a mobo upgrade.
Chris

A nice source for some SVG inspiration might be PyChart, another python plotting system, that has a fully functional SVG backend: http://www.hpl.hp.com/personal/Yasushi_Saito/pychart.
I like the looks/features of this package, but it lacks interactivity/GUI support and relies on ghostscript for rendering images.

>>>>> "cfuller" == cfuller <cf...@th...> writes:
 cfuller> Ack, I'll try not to let it go to my head! Hacking on
 cfuller> backends is more then I bargained for! I'm no good at
 cfuller> making bitmaps, so someone else should figure out what
 cfuller> the button should look like. I'll make my demo into a
 cfuller> proper dialog, hook it up to generic button, and I'll
 cfuller> even take a whack at the wx backend, but that will be
 cfuller> tricky, since it won't even run on my machine for some
 cfuller> reason. I suppose you just got a reluctant wx developer,
 cfuller> if I'm going to debug that :)
That would be great - there are some known gtk related problems with
the latest wx release that are independent of matplotlib. What
platform are you having trouble with?
As for the pixmap, what we've done in the past is I pick some suitable
gtk stock icon and we just copy that into a pixmap.
 cfuller> If all goes well, I'll see about the ticklabels.
 cfuller> As for your question about axes_demo, I was thinking
 cfuller> along these lines while developing the code. It would be
 cfuller> simple enough to generalize to working with a list of
 cfuller> axes, rather than passing a figure and querying the
 cfuller> figure to get the list. A bounding box would have to be
 cfuller> passed along also, to stand in for the full figure
 cfuller> [0,1],[0,1] box. A default bounding box could be defined
 cfuller> by the axes. It should be fairly simple to implement. I
 cfuller> just thought it was getting a little too ambitious :) (or
 cfuller> at least more then my needs required, if you prefer!)
I don't think its necessary to support Axes, just to fail gracefully.
They are only used when people place them explicity, so I don't know
that it's necessary to interactively resize them. Failing gracefully
with something along the lines of
if not isinstance(ax, axes.Subplot):
 error_msg('only works with subplots')
would satisfy me.
 cfuller> For that matter, it doesn't have to work on only
 cfuller> axes. Any rectangular region would do. The Text class
 cfuller> even has get_position and set_position methods! See the
 cfuller> kind of trouble I get into?
Whoa now, easy there. 
 cfuller> Chris Fuller
 cfuller> -------------------------------------------------------
 cfuller> This SF.Net email sponsored by Black Hat Briefings &
 cfuller> Training. Attend Black Hat Briefings & Training, Las
 cfuller> Vegas July 24-29 - digital self defense, top technical
 cfuller> experts, no vendor pitches, unmatched networking
 cfuller> opportunities. Visit www.blackhat.com
 cfuller> _______________________________________________
 cfuller> Matplotlib-devel mailing list
 cfuller> Mat...@li...
 cfuller> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Ack, I'll try not to let it go to my head! Hacking on backends is more then I bargained for! I'm no good at making bitmaps, so someone else should figure out what the button should look like. I'll make my demo into a proper dialog, hook it up to generic button, and I'll even take a whack at the wx backend, but that will be tricky, since it won't even run on my machine for some reason. I suppose you just got a reluctant wx developer, if I'm going to debug that :)
If all goes well, I'll see about the ticklabels.
As for your question about axes_demo, I was thinking along these lines while developing the code. It would be simple enough to generalize to working with a list of axes, rather than passing a figure and querying the figure to get the list. A bounding box would have to be passed along also, to stand in for the full figure [0,1],[0,1] box. A default bounding box could be defined by the axes. It should be fairly simple to implement. I just thought it was getting a little too ambitious :) (or at least more then my needs required, if you prefer!)
For that matter, it doesn't have to work on only axes. Any rectangular region would do. The Text class even has get_position and set_position methods! See the kind of trouble I get into?
Chris Fuller

>>>>> "cfuller" == cfuller <cf...@th...> writes:
 cfuller> I've been playing with matplotlib a couple of weeks
 cfuller> now. That nasty memory leak was starting to turn me off,
 cfuller> and then got fixed right on cue! I've had a hell of a
 cfuller> time finding a good plotting system to replace BLT, so
 cfuller> that was a relief.
There have been some additional memory leak fixes since 0.54.2. Glad
we could keep you on board!
 cfuller> Anyhow, I noticed my titles overwriting the x axes of
 cfuller> adjacent subplots, and so I wrote a little function that
 cfuller> shifts subplots around. That's not terribly interesting,
 cfuller> but I have a compulsive habit of making everything I do
 cfuller> as general as possible. The result is a system for
 cfuller> controlling figure layout based on six parameters, three
 cfuller> for each axis. As well as a rather elaborate demo. The
 cfuller> basic demo was done in an hour, but I couldn't leave well
 cfuller> enough alone!
Ahh, just the kind of developer we need.... 
 cfuller> I tried to get the docstrings right, but haven't checked
 cfuller> them. I also included a mathematical derivation at the
 cfuller> end of the file, and I don't know what the documentation
 cfuller> scripts will make of that.
 cfuller> There's no error checking. None should be needed, as long
 cfuller> as all the parameters are numeric. Some curious results
 cfuller> are very possible, but nothing breaks.
 cfuller> If you find the documentation and API (and whatever else)
 cfuller> worthy, you can include it in the next release/current
 cfuller> CVS if you think it appropriate.
I really liked your demo. So much that I think we should include it
into the distribution and incorporate versions of your widgets for
each backend. I think we should have a button on the standard toolbar
that launches your dialog box. I can do the one for GTK - perhaps you
or Todd would like to incorporate your changes into backend_tkagg so
that a toolbar button launches the dialog box you wrote.
It would also be nice to add checkboxes for turning off y tick labels
for all but the first column and turning off x tick labels for all but
the last row.
Any takers for doing the wx version?
Another question: what would happen if your code were run on non
subplot axes, eg with those examples/axes_demo.py?
A word of warning: in your demo code, you define a function set.
There is a matplotlib.matlab function with the same name...
 cfuller> Oh, and if the user wants to shift individual subplots
 cfuller> around, that function is still present.

I've been playing with matplotlib a couple of weeks now. That nasty memory leak was starting to turn me off, and then got fixed right on cue! I've had a hell of a time finding a good plotting system to replace BLT, so that was a relief.
Anyhow, I noticed my titles overwriting the x axes of adjacent subplots, and so I wrote a little function that shifts subplots around. That's not terribly interesting, but I have a compulsive habit of making everything I do as general as possible. The result is a system for controlling figure layout based on six parameters, three for each axis. As well as a rather elaborate demo. The basic demo was done in an hour, but I couldn't leave well enough alone!
I tried to get the docstrings right, but haven't checked them. I also included a mathematical derivation at the end of the file, and I don't know what the documentation scripts will make of that.
There's no error checking. None should be needed, as long as all the parameters are numeric. Some curious results are very possible, but nothing breaks.
If you find the documentation and API (and whatever else) worthy, you can include it in the next release/current CVS if you think it appropriate.
Oh, and if the user wants to shift individual subplots around, that function is still present.
Chris Fuller

I've been using matplotlib in a WX application. The particular application
can uses many matplotlib figures within a MDI window class. The problem
appears when there are about seven windows active in the MDI, and an eight
is added. This causes a repaint of all seven matplotlib figures, which then
triggers the following assertion
 
PyAssertionError: C++ assertion "wxAssertFailure" failed in
"..\src\msw\dcmemory.cpp (133): Couldn't select a bitmap into wxMemoryDC
 
This appears on windows XP professional, Python 2.3, wxPython 2.5.1.5,
matplotlib 0.54.
 
The code snippet below reproduces the problem. Basically calling "show()" in
a loop forces repaint of the same window many times. After a while a strange
stack trace appears with the assertion above. Sometimes the stack trace
creates garbage all over the screen which has to be cleared by repainting
the whole screen.
 
 
import wx
import matplotlib
matplotlib.use('WX')
 
from matplotlib.matlab import *
 
class App(wx.App):
 """Application class."""
 
 def OnInit(self):
 t = arange(0.0, 2.0, 0.01)
 s = sin(2*pi*t)
 l = plot(t, s, linewidth=1.0)
 xlabel('time (s)')
 ylabel('voltage (mV)')
 title('About as simple as it gets, folks')
 legend('line', loc='upper right')
 for i in range(100):
 grid(True)
 show()
 # end for
 
 return True
 
#---------------------------------------------------------------------------
# run the app
app = App()
app.MainLoop()

Ok, I did the test, removed this strange file (not a valid TTF file,
checked that too) and everything work nicely now with 0.60b.
If you want to reproduce this behavior (cannot call it a bug anymore, it
is really my fault having a corrupted font directory), it is sufficient
to create a non-font file in the Font directory, with TTF extension (a
copy in a dos prompt is necessary, file explorer try to install the
"font" on drag&drop), remove the font cache to force a rescanning, and
the crash occur (using numarray, I still do not know why it worked with
numeric...All I can say is that a non-valid ttf file cause a crash on
matplotlib+numarray...)
I do not know if nvestigating this is worthy, as nobody should have a
non-valid ttf file in the font directory anyway, but maybe this will
make the TTF scanning code more robust? 
Thanks for your help and sorry crying "Bug, bug" without real reason :-/
Best regards,
Greg.