Menu
▾
▴
matplotlib-users
|
From: Eric E. <ems...@ob...> - 2004-12-08 08:20:36
|
Hi, I am now trying to switch from ppgplot to matplotlib and I really like the latter for the much nicer plots and functionalities (although limitations such as the absence of contour plots is a critical one). However, I just made a small script to plot 10 small subplots on a single window repeatedly (going through slices of an array each time) and it is bloody slooooooooow (a very large factor slower than anything I can use to do the same thing with python and some graphical functions). I personnally think this is a major limitation (with the contours) of that piece of soft, and may discourage many (and myself). Is there a way to improve (dramatically) this? Is there a plan there? thanks in advance, Eric Emsellem P.S.: by the way I solved the cursor problem I posted (and got no answer) by defining a new cursor class (something already hinted by many on the web), if anyone is interested.. -- =============================================================== Observatoire de Lyon ems...@ob... 9 av. Charles-Andre tel: +33 4 78 86 83 84 69561 Saint-Genis Laval Cedex fax: +33 4 78 86 83 86 France http://www-obs.univ-lyon1.fr/eric.emsellem =============================================================== |
|
From: Arnd B. <arn...@we...> - 2004-12-08 08:49:32
|
Hi Eric,
On Wed, 8 Dec 2004, Eric Emsellem wrote:
[...]
> P.S.: by the way I solved the cursor problem I posted (and got no answer)
> by defining a new cursor class (something already hinted
> by many on the web), if anyone is interested..
I would be very interested in this - maybe you could
post it here (also for the archive ;-).
If possible it would be nice to see this integrated into matplotlib
because this sounds like a replacement of scipy.xplt/pygist's
mouse command (or ppgplot's pgband?).
Best,
Arnd
P.S.: I agree on the speed issues. Unfortunately
most of the newer python graphics packages tend to be
slower than older packages.
For example scipy.xplt (aka pygist) see
http://bonsai.ims.u-tokyo.ac.jp/~mdehoon/software/python/index.html
is reasonably fast.
We have set up a PlottingCanvas for wxPython
for our specific needs of fast plotting of single points
and moving objects,
http://www.physik.tu-dresden.de/~baecker/python/plot.html
But this is by far not a fully featured plotting program,
though maybe some of the ideas used there to speed
up things could be used in matplotlib
(note that I state this with complete ignorance
of matplotlib's interna).
|
|
From: Perry G. <pe...@st...> - 2004-12-08 15:34:54
|
On Dec 8, 2004, at 3:29 AM, Eric Emsellem wrote: > Hi, > > I am now trying to switch from ppgplot to matplotlib and I > really like the latter for the much nicer plots and functionalities > (although limitations such as the absence of contour plots is a > critical one). There is progress being made on contour plots. We've implemented a basic version that John Hunter is looking at now. > > However, I just made a small script to plot 10 small subplots > on a single window repeatedly (going through slices of an array each > time) > and it is bloody slooooooooow (a very large factor slower than anything > I can use to do the same thing with python and some graphical > functions). > > I personnally think this is a major limitation (with the contours) of > that piece of soft, and may discourage many (and myself). > Could you give some indication of what speed you are getting vs what you have gotten under other plotting packages? How big is the slice (how many points)? What kind of plot? Showing the actual script may help a lot in understanding why it is so slow. There may be other ways that are faster, or it will at least point to the main bottleneck that could stand improvement. This complaint is too general to be helpful. I'm not sure it should be matplotlib's goal to be the fastest package around, but it should be fast enough for ordinary plotting (which means different things to different people of course). > Is there a way to improve (dramatically) this? Is there a plan there? > > thanks in advance, > > Eric Emsellem > > P.S.: by the way I solved the cursor problem I posted (and got no > answer) > by defining a new cursor class (something already hinted > by many on the web), if anyone is interested.. > I missed this post (I'm too busy at the moment to read all posts). Yes, having this functionality is important. Some of this is possible now but John has this at his fingertips (I can't recall the details). If I have time I'll see if I can dig this up. Perry |
|
From: LUK S. <shu...@po...> - 2004-12-09 04:13:18
|
Perry Greenfield wrote: > > On Dec 8, 2004, at 3:29 AM, Eric Emsellem wrote: > >> Hi, >> >> I am now trying to switch from ppgplot to matplotlib and I >> really like the latter for the much nicer plots and functionalities >> (although limitations such as the absence of contour plots is a >> critical one). > > > There is progress being made on contour plots. We've implemented a basic > version that John Hunter is looking at now. > It's really nice to hear that. As Eric said, it's one thing that is sorely missed. As it's being implemented, here is a little wish. I'd like to see the capability of contouring on an arbitrary grid. That is, matplotlab would be able to plot the contours of a function f(x_i, y_i) given on an arbitrary set of points (x_i, y_i), not necessarily set out on a regular grid. Regards, ST -- |
|
From: Chris B. <Chr...@no...> - 2004-12-09 19:16:16
|
LUK ShunTim wrote: > As it's being implemented, here is a little wish. I'd like to see the > capability of contouring on an arbitrary grid. That is, matplotlab would > be able to plot the contours of a function f(x_i, y_i) given on an > arbitrary set of points (x_i, y_i), not necessarily set out on a regular > grid. This would be nice, but it's a bit of a project. One way to do it would be to Delaunay triangulate the points, then you can compute the contours from the triangular grid. Delaunay triangulation is not trivial, and you really want to use an efficient scheme to do it. One possibility is: http://www-2.cs.cmu.edu/~quake/triangle.html It is very robust and fast, and can be compiled as a library. I've been planning for ages to write a Python wrapper for it, but haven't gotten to it yet. If someone works on this, I'd like to help. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chr...@no... |
|
From: Perry G. <pe...@st...> - 2004-12-09 19:32:47
|
On Dec 9, 2004, at 2:12 PM, Chris Barker wrote: > LUK ShunTim wrote: >> As it's being implemented, here is a little wish. I'd like to see the >> capability of contouring on an arbitrary grid. That is, matplotlab >> would be able to plot the contours of a function f(x_i, y_i) given on >> an arbitrary set of points (x_i, y_i), not necessarily set out on a >> regular grid. > > This would be nice, but it's a bit of a project. One way to do it > would be to Delaunay triangulate the points, then you can compute the > contours from the triangular grid. Delaunay triangulation is not > trivial, and you really want to use an efficient scheme to do it. One > possibility is: > > http://www-2.cs.cmu.edu/~quake/triangle.html > > It is very robust and fast, and can be compiled as a library. I've > been planning for ages to write a Python wrapper for it, but haven't > gotten to it yet. > > If someone works on this, I'd like to help. > > -Chris > Actually, I believe that the low level contour engine we are using supports this. It takes 2-d arrays for both x and y that represent the x and y coordinates of the array being contoured and generates plotting points based on those x and y arrays. These arrays allow for irregular grids. At the moment, the routine generates uniform x and y grids as arguments to pass along, but it could be generalized to take these as extra arguments without much trouble. Let me know if I misunderstand what you are trying to do. Perry |
|
From: Perry G. <pe...@st...> - 2004-12-09 19:50:16
|
On Dec 9, 2004, at 2:33 PM, Perry Greenfield wrote: > > Actually, I believe that the low level contour engine we are using > supports this. It takes 2-d arrays for both x and y that represent > the x and y coordinates of the array being contoured and generates > plotting points based on those x and y arrays. These arrays allow > for irregular grids. At the moment, the routine generates uniform > x and y grids as arguments to pass along, but it could be generalized > to take these as extra arguments without much trouble. > > Let me know if I misunderstand what you are trying to do. > > Perry > Correction. It already supports that feature now (but it isn't checked in yet). |
|
From: Chris B. <Chr...@no...> - 2004-12-09 21:17:14
|
Perry Greenfield wrote:
>> Actually, I believe that the low level contour engine we are using
>> supports this. It takes 2-d arrays for both x and y that represent
>> the x and y coordinates of the array being contoured and generates
>> plotting points based on those x and y arrays. These arrays allow
>> for irregular grids.
completely irregular? or only orthogonal structured grids. From your
description, it sounds like the later. Could it take an unstructured set
of (x,y,z) points and contour the z values?
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...
|
|
From: John H. <jdh...@ac...> - 2004-12-10 20:45:21
|
>>>>> "Chris" == Chris Barker <Chr...@no...> writes:
Chris> Perry Greenfield wrote:
>>> Actually, I believe that the low level contour engine we are
>>> using supports this. It takes 2-d arrays for both x and y that
>>> represent the x and y coordinates of the array being contoured
>>> and generates plotting points based on those x and y
>>> arrays. These arrays allow for irregular grids.
Chris> completely irregular? or only orthogonal structured
Chris> grids. From your description, it sounds like the
Chris> later. Could it take an unstructured set of (x,y,z) points
Chris> and contour the z values?
The latter, I believe. The contouring routine was implemented by
Nadia Dencheva (CCd on this mail) and is based on a gist routine. You
can read more about the core routine at
http://scipy.net/cgi-bin/viewcvsx.cgi/*checkout*/scipy1/xplt/src/gist/gcntr.c?rev=HEAD&content-type=text/plain.
The contour routines have been checked into CVS. A simple example can
be found in examples/contour_demo.py in CVS. We have some rudimentary
support for labeling (auto-legend and/or brute-force use of the text
command). It would be nice to develop a point and click labeling
widget and/or an auto-labeling routine. Contributors of course always
welcome!
JDH
|
|
From: Perry G. <pe...@st...> - 2004-12-10 21:24:59
|
John Hunter Wrote: > >>>>> "Chris" == Chris Barker <Chr...@no...> writes: > > Chris> Perry Greenfield wrote: > > >>> Actually, I believe that the low level contour engine we are > >>> using supports this. It takes 2-d arrays for both x and y that > >>> represent the x and y coordinates of the array being contoured > >>> and generates plotting points based on those x and y > >>> arrays. These arrays allow for irregular grids. > > Chris> completely irregular? or only orthogonal structured > Chris> grids. From your description, it sounds like the > Chris> later. Could it take an unstructured set of (x,y,z) points > Chris> and contour the z values? > > The latter, I believe. The contouring routine was implemented by > Nadia Dencheva (CCd on this mail) and is based on a gist routine. You Yes, the latter. For an unstructured set some other approach would be needed. Sorry if I misunderstood. I thought what was being discussed was irregular spacings rather than irregular organization. Perry |
|
From: Chris B. <Chr...@no...> - 2004-12-11 00:46:19
|
John Hunter wrote:
>>>>>>"Chris" == Chris Barker <Chr...@no...> writes:
> Chris> completely irregular? or only orthogonal structured
> Chris> grids. From your description, it sounds like the
> Chris> later. Could it take an unstructured set of (x,y,z) points
> Chris> and contour the z values?
>
> The latter, I believe.
yup. from the below referenced link:
"""
General purpose contour tracer for quadrilateral meshes.
"""
So it won't handle arbitrary unstructured points, but it's nice none the
less. With an interpolator to a rectangular grid, you could use it for
any array of points, I think someone posted an example of this on the
matplotlib list.
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...
|
|
From: Peter G. <pgr...@ge...> - 2004-12-09 20:05:40
Attachments:
axPnuLC2004-12-09_09-38-41.70038018.png
|
Perry Greenfield wrote: > > On Dec 9, 2004, at 2:12 PM, Chris Barker wrote: > >> LUK ShunTim wrote: >> >>> As it's being implemented, here is a little wish. I'd like to see >>> the capability of contouring on an arbitrary grid. That is, >>> matplotlab would be able to plot the contours of a function f(x_i, >>> y_i) given on an arbitrary set of points (x_i, y_i), not necessarily >>> set out on a regular grid. >> >> >> This would be nice, but it's a bit of a project. One way to do it >> would be to Delaunay triangulate the points, then you can compute the >> contours from the triangular grid. Delaunay triangulation is not >> trivial, and you really want to use an efficient scheme to do it. One >> possibility is: >> >> http://www-2.cs.cmu.edu/~quake/triangle.html >> >> It is very robust and fast, and can be compiled as a library. I've >> been planning for ages to write a Python wrapper for it, but haven't >> gotten to it yet. >> >> If someone works on this, I'd like to help. >> >> -Chris >> > > Actually, I believe that the low level contour engine we are using > supports this. It takes 2-d arrays for both x and y that represent > the x and y coordinates of the array being contoured and generates > plotting points based on those x and y arrays. These arrays allow > for irregular grids. At the moment, the routine generates uniform > x and y grids as arguments to pass along, but it could be generalized > to take these as extra arguments without much trouble. I use Hardy's multiquadric interpolation to to do the math, then use imshow (or pcolor) to make a surface map. I only have data for the 120 points (where the circle are - those are actuators), and interpolate the rest. If people are interested, I can clean up the code a little and post it. |
|
From: Chris B. <Chr...@no...> - 2004-12-09 21:15:17
|
Peter Groszkowski wrote:
> I use Hardy's multiquadric interpolation to to do the math, then use
> imshow (or pcolor) to make a surface map. I only have data for the 120
> points (where the circle are - those are actuators), and interpolate the
> rest.
>
> If people are interested, I can clean up the code a little and post it.
Please do.
--
Christopher Barker, Ph.D.
Oceanographer
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...
|
|
From: John H. <jdh...@ac...> - 2004-12-10 20:52:40
|
>>>>> "Peter" == Peter Groszkowski <pgr...@ge...> writes:
Peter> I use Hardy's multiquadric interpolation to to do the math,
Peter> then use imshow (or pcolor) to make a surface map. I only
Peter> have data for the 120 points (where the circle are - those
Peter> are actuators), and interpolate the rest.
Peter> If people are interested, I can clean up the code a little
Peter> and post it.
This sounds pretty close to matlab's griddata function. It would be
very nice to have this in matplotlib.mlab, perhaps as a wrapper to
some core scipy functionality, which could be conditionally imported.
What requirements does your code have -- pure python, extension code,
scipy, numarray?
Here is the matlab docstring, FYI
GRIDDATA Data gridding and surface fitting.
ZI = GRIDDATA(X,Y,Z,XI,YI) fits a surface of the form Z = F(X,Y)
to the data in the (usually) nonuniformly-spaced vectors (X,Y,Z)
GRIDDATA interpolates this surface at the points specified by
(XI,YI) to produce ZI. The surface always goes through the data
points. XI and YI are usually a uniform grid (as produced by
MESHGRID) and is where GRIDDATA gets its name.
XI can be a row vector, in which case it specifies a matrix with
constant columns. Similarly, YI can be a column vector and it
specifies a matrix with constant rows.
[XI,YI,ZI] = GRIDDATA(X,Y,Z,XI,YI) also returns the XI and YI
formed this way (the results of [XI,YI] = MESHGRID(XI,YI)).
[...] = GRIDDATA(...,'method') where 'method' is one of
'linear' - Triangle-based linear interpolation (default).
'cubic' - Triangle-based cubic interpolation.
'nearest' - Nearest neighbor interpolation.
'v4' - MATLAB 4 griddata method.
defines the type of surface fit to the data. The 'cubic' and 'v4'
methods produce smooth surfaces while 'linear' and 'nearest' have
discontinuities in the first and zero-th derivative respectively. All
the methods except 'v4' are based on a Delaunay triangulation of the
data.
See also GRIDDATA3, GRIDDATAN, DELAUNAY, INTERP2, MESHGRID.
|
|
From: Peter G. <pgr...@ge...> - 2004-12-10 21:32:35
|
John Hunter wrote: >>>>>> "Peter" == Peter Groszkowski <pgr...@ge...> writes: >>>>> > > Peter> I use Hardy's multiquadric interpolation to to do the math, > Peter> then use imshow (or pcolor) to make a surface map. I only > Peter> have data for the 120 points (where the circle are - those > Peter> are actuators), and interpolate the rest. > > Peter> If people are interested, I can clean up the code a little > Peter> and post it. > > This sounds pretty close to matlab's griddata function. Yup. That's the functionality I needed. As it says in MATLAB docstrig below, GRIDDATA uses Delaunay triangulation however. > It would be > very nice to have this in matplotlib.mlab, perhaps as a wrapper to > some core scipy functionality, which could be conditionally imported. > What requirements does your code have -- pure python, extension code, > scipy, numarray? > The interpolating is done all in python with the use of Numeric (this is what I have been using, and what my matplotlib installation uses - maybe will upgrade to numarray one of these days). Performance wise, It's not very practical for a very large number of points N as it has to solve a NxN system (my N=120 and takes ~2.3seconds on a P4 3.2Ghz with 2GB ram - cant remember how long MATLAB's griddata took). Maybe numarray would be faster?! The drawing of the mirror, actuators, etc is done using matplotlibs imshow(), plot() and fill() - all very straight forward. I will post the code in the next few days when I have a minute to clean it up a litte. Cheers, -- Peter Groszkowski Gemini Observatory Tel: +1 808 9742509 670 N. A'ohoku Place Fax: +1 808 9359235 Hilo, Hawai'i 96720, USA > Here is the matlab docstring, FYI > > GRIDDATA Data gridding and surface fitting. > ZI = GRIDDATA(X,Y,Z,XI,YI) fits a surface of the form Z = F(X,Y) > to the data in the (usually) nonuniformly-spaced vectors (X,Y,Z) > GRIDDATA interpolates this surface at the points specified by > (XI,YI) to produce ZI. The surface always goes through the data > points. XI and YI are usually a uniform grid (as produced by > MESHGRID) and is where GRIDDATA gets its name. > > XI can be a row vector, in which case it specifies a matrix with > constant columns. Similarly, YI can be a column vector and it > specifies a matrix with constant rows. > > [XI,YI,ZI] = GRIDDATA(X,Y,Z,XI,YI) also returns the XI and YI > formed this way (the results of [XI,YI] = MESHGRID(XI,YI)). > > [...] = GRIDDATA(...,'method') where 'method' is one of > 'linear' - Triangle-based linear interpolation (default). > 'cubic' - Triangle-based cubic interpolation. > 'nearest' - Nearest neighbor interpolation. > 'v4' - MATLAB 4 griddata method. > defines the type of surface fit to the data. The 'cubic' and 'v4' > methods produce smooth surfaces while 'linear' and 'nearest' have > discontinuities in the first and zero-th derivative respectively. All > the methods except 'v4' are based on a Delaunay triangulation of the > data. > > See also GRIDDATA3, GRIDDATAN, DELAUNAY, INTERP2, MESHGRID. > > > > |
|
From: Norbert N. <No...@ne...> - 2004-12-09 16:32:16
|
Am Mittwoch, 8. Dezember 2004 16:35 schrieb Perry Greenfield:
> Could you give some indication of what speed you are getting vs what you
> have gotten under other plotting packages?
I have experienced some extreme inefficiency using errorbar plots for large
datasets. Obviously, the "hlines" routine is a huge bottleneck. Would it be
possible, in principle, to use an efficient collection instead?
--
_________________________________________Norbert Nemec
Bernhardstr. 2 ... D-93053 Regensburg
Tel: 0941 - 2009638 ... Mobil: 0179 - 7475199
eMail: <No...@Ne...>
|
|
From: John H. <jdh...@ac...> - 2004-12-09 16:41:00
|
>>>>> "Norbert" == Norbert Nemec <No...@ne...> writes:
Norbert> I have experienced some extreme inefficiency using
Norbert> errorbar plots for large datasets. Obviously, the
Norbert> "hlines" routine is a huge bottleneck. Would it be
Norbert> possible, in principle, to use an efficient collection
Norbert> instead?
As Perry noted, it would be nice to see some of Eric's code to see if
this is the kind of bottleneck he is bumping into.
It would be very straightforward to use collections here is what they
were designed for - removing bottlenecks created by instantiating many
similar objects. I've never plotted a large number of errorbar lines
so haven't bumped into this one.
Note this might break some code which is relying on the fact that the
errorbar routing is returning a list of errorbar lines. collections
are designed to respond similarly to lists of lines under the set
command. Eg
set(lines, color='r', linewidth=4)
and
set(collection, color='r', linewidth=4)
will both work.
But if someone is currently doing
lines[2].set_color('g')
or
for line in lines:
line.set_something(else)
there would be a backward incompatibility with this change. Note it
would be possible to define setitem, getitem, and possibly setslice,
getslice and iter for collections to make them behave more like lists
of objects, which would be nice if we (you) want to make this change.
Is anyone changing the properties of individual error lines returned
by errorbar?
JDH
|
|
From: Norbert N. <Nor...@gm...> - 2004-12-09 18:38:42
|
Am Donnerstag, 9. Dezember 2004 17:38 schrieb John Hunter:
> Note it
> would be possible to define setitem, getitem, and possibly setslice,
> getslice and iter for collections to make them behave more like lists
> of objects, which would be nice if we (you) want to make this change.
Would that be possible at all? Do individual items in a collection have an
identity at all that could be exposed in Python? Do they have individual
properties?
Note, that I probably won't have the time to look into this matter myself.
Maybe one day, but certainly not in the near future.
Ciao,
Nobbi
--
_________________________________________Norbert Nemec
Bernhardstr. 2 ... D-93053 Regensburg
Tel: 0941 - 2009638 ... Mobil: 0179 - 7475199
eMail: <No...@Ne...>
|
|
From: Matt N. <new...@ca...> - 2004-12-09 19:52:35
|
Hi,
I'm doing relatively simple line plots the WXAgg backend, but I
also find matplotlib to be somewhat slower than I'd hope for.
On a WindowsXP box (P4 1.7GHz, 512Mb RAM), in a wx event loop
issuing a plot() as fast as I can go, I get about 1 plot every
0.25 to 0.30 sec. This is just barely fast enough for my needs.
If I could reliably go at 10 plots/sec, that would be great.
It turns out that the dynamic_demo_wx.py example does go much
faster, but it does not actually re-do a plot(). Instead it just
changes the subplots line data. That's interesting, but I need
the view to be adjusted as well, as the scale will change with
time for my data. So far, I'm just re-issuing plot(), but I'd be
willing to do something slightly fancier.
Anyway, that led me to try to track down where the slowness in
plot() was coming from. Using nothing more sophisticated than
print statements, I believe the performance bottleneck is in
axis.py in Axis.draw(), in this block:
for tick, loc, label in zip(majorTicks, majorLocs, majorLabels):
if not interval.contains(loc): continue
seen[loc] = 1
tick.update_position(loc)
tick.set_label1(label)
tick.set_label2(label)
tick.draw(renderer)
extent = tick.label1.get_window_extent(renderer)
ticklabelBoxes.append(extent)
For me, this block (run twice for a plot()) typically takes at
least 50% of the plot time. Commenting out the
tick.draw(renderer) and the following two 'extent' lines roughly
doubles the drawing rate (though no grid or ticks are shown). I
was surprised by this, but have not tracked it down much beyond
this. I'm not using mathtext in the labels and had only standard
numerical Tick labels in this example.
I don't know if this is applicable to the slowness of the contour
plots or error bars or if collections would help here. But it
doesn't seem like tick drawing should be the bottleneck. Anyway,
this seems like a simple place to test in other situations, and
may be a good place to look for possible optimizations.
Thanks,
--Matt
|
|
From: John H. <jdh...@ac...> - 2004-12-10 21:31:11
|
>>>>> "Matt" == Matt Newville <new...@ca...> writes:
Matt> For me, this block (run twice for a plot()) typically takes
Matt> at least 50% of the plot time. Commenting out the
Matt> tick.draw(renderer) and the following two 'extent' lines
Matt> roughly doubles the drawing rate (though no grid or ticks
Matt> are shown). I was surprised by this, but have not tracked it
Matt> down much beyond this. I'm not using mathtext in the labels
Matt> and had only standard numerical Tick labels in this example.
Matt> I don't know if this is applicable to the slowness of the
Matt> contour plots or error bars or if collections would help
Matt> here. But it doesn't seem like tick drawing should be the
Matt> bottleneck. Anyway, this seems like a simple place to test
Matt> in other situations, and may be a good place to look for
Matt> possible optimizations.
This is a known bottleneck. Text layout is non-trivial in matplotlib.
Put it this way: you don't get multiline text with arbitrary rotation,
font properties, horizontal, vertical, and multiline alignment for
free. Take a look at matplotlib.text.Text._get_layout.
I do cache the layout information because I've seen this performance
hit on animated demos before. But if your text properties are
changing, caching doesn't help. The cache key is returned by
Text.get_prop_tup.
It is probably worthwhile to run your animation through the profiler
so we can get a better idea of where exactly the problems are. I
think the matrix multiplication that _get_layout uses for rotations is
slow. It would be possible to special case the most common case
(rotation angle = 0) for some speedups, but the code is already fairly
hairy so I've been resisting special casing it.
FYI, the wxagg backend uses string methods to transfer the agg image
to the canvas. tk and gtk use extension code. fltk uses a python
buffer object. I investigated the latter for wxagg but couldn't make
it work. You may want to look into FigureCanvasWxAgg.draw to see if
you can do this image transfer faster, possibly adding some extension
code. If you do go the extension code route, I suggest you try/except
the import on your extension code and fall back on the string method
already in place.
Oh, I added "newville" to the list of CVS developers. Everyone,
welcome Matt, the new wx maintainer!
JDH
|
|
From: John H. <jdh...@ac...> - 2004-12-09 16:45:26
|
>>>>> "Eric" == Eric Emsellem <ems...@ob...> writes:
Eric> P.S.: by the way I solved the cursor problem I posted (and
Eric> got no answer) by defining a new cursor class (something
Eric> already hinted by many on the web), if anyone is
Eric> interested..
Been out of town at meetings for the last week...
Have you seen
http://matplotlib.sourceforge.net/examples/coords_demo.py, which shows
how to connect to mouse motion and click? The interface is being
streamlined in 0.65. Ie in CVS, one simply needs to do
def on_click(event): pass
connect('button_press_event', on_click)
Currently key_press_event is not implemented (though mouse move and
motion to capture and report key presses as event.key). We added this
because this is how we do the event handling across backends for the
toolbar. There are also some fixes in CVS to make disconnects work
properly, eg in the tk backend.
It would be fairly straightforward to add a key_press_event under the
same framework.
For "cursoring", see the *cursor*.py examples in the examples subdir
of the matplotlib src distro.
But please also post your solution which may be useful....
JDH
|
|
From: Eric E. <ems...@ob...> - 2004-12-09 17:16:37
|
Hi,
1. slow plot
2. cursor issue
3. key press event !
-------
1/
Here is the piece of code which is quite slow I think. Compared to
pgplot this
is a factor of more than 10. It does first draw a default plot (0,1 ?)
and then
overplot on it for each subplot.
for this particular case I have 10 subplots. The slices are made of
about 10-20
points each only (stored in a 3D array which is 48x5x20 points).
I hope this answers the question. Sorry for the ''specifics''.
for i in arange(ncoef) :
subplot(nrow, 2, i+1)
if i > 1 :
temparray = self.Vcoef[indgal][i][:minind] /
self.Vcoef[indgal][1][:minind]
plot(self.Vrad[indgal][:minind], temparray, 'b-o', ms=4)
else :
plot(self.Vrad[indgal][:minind],
self.Vcoef[indgal][i][:minind], 'b-o', ms=4)
ylabel('$C_{%d'%i+'}$')
for i in arange(ncoef) :
j = i + ncoef
subplot(nrow, 2, j+1)
plot(self.Vrad[indgal][:minind],
self.Vphi[indgal][i][:minind], 'b-o', ms=4)
ylabel('$\phi_{%d'%i+'}$')
2/ the cursor issue and how to interact with it:
yes indeed the solution I took is close to what is shown in some examples.
I used a new class which I then use later on in interactive mode or not.
Below is a simple/shortened example of the structure I create by just
transferring
the data (x,y,key, etc) to the cursor structure. I can then use : toto =
cursor()
to have it working. (I in fact define several different cursor_* classes
for different purposes).
So sorry if my mail sounded like ''I have found a new way...''.
class cursor :
def __init__(self):
print 'Class initialized'
self.figure = Figure()
self.canvas = get_current_fig_manager().canvas
self.canvas.mpl_connect('button_press_event', self.on_click)
self.x = 0
self.y = 0
self.button = 1
def on_click(self, event):
self.x = event.x
self.y = event.y
self.xd = event.xdata
self.yd = event.ydata
self.button = event.button
...
3/ key press event
>Currently key_press_event is not implemented (though mouse move and
>motion to capture and report key presses as event.key). We added this
>because this is how we do the event handling across backends for the
>toolbar. There are also some fixes in CVS to make disconnects work
>properly, eg in the tk backend.
>
>It would be fairly straightforward to add a key_press_event under the
>same framework.
>
>
>
That WOULD be great since this is exactly what I needed. For example being
able to type ''h'' to make an horizontal cut of my image at the location
corresponding
to the mouse position.... I do that easily with ppgplot for example.
--
===============================================================
Observatoire de Lyon ems...@ob...
9 av. Charles-Andre tel: +33 4 78 86 83 84
69561 Saint-Genis Laval Cedex fax: +33 4 78 86 83 86
France http://www-obs.univ-lyon1.fr/eric.emsellem
===============================================================
|
|
From: John H. <jdh...@ac...> - 2004-12-10 21:03:56
|
>>>>> "Eric" == Eric Emsellem <ems...@ob...> writes:
Eric> Hi, 1. slow plot 2. cursor issue 3. key press event !
Eric> ------- 1/ Here is the piece of code which is quite slow I
Eric> think. Compared to pgplot this is a factor of more than
Eric> 10. It does first draw a default plot (0,1 ?) and then
Eric> overplot on it for each subplot.
Eric> for this particular case I have 10 subplots. The slices are
Eric> made of about 10-20 points each only (stored in a 3D array
Eric> which is 48x5x20 points). I hope this answers the
Eric> question. Sorry for the ''specifics''.
Plots of this size should be extremely fast - you should be able to
plot arrays 10 times this big with good performance. From your
description "It does first draw a default plot ..and then overplot on
it for each subplot." it sounds like you may have interactive mode
turned on. This would kill your performance in a case like this,
because the entire figure would be redrawn with the update of every
single plotting command. See
http://matplotlib.sourceforge.net/interactive.html and
http://matplotlib.sourceforge.net/faq.html#SHOW .
To definitively determine what mode you are in, run your script with
> python simple_plot.py --verbose-helpful
and verify that 'interactive is False'. Fernando Perez's ipython has
support for running scripts from the interactive shell, turning off
interactive mode for the duration of the run, and then restoring it.
If this doesn't solve your problem please
- post your entire script
- report the output of verbose-helpful (requires matplotlib 0.64)
- what is your platform, machine specs, etc?
- how are you running the script (IDE, from the command prompt, etc)
JDH
|
|
From: Perry G. <pe...@st...> - 2004-12-11 02:06:36
|
John Hunter wrote: > Plots of this size should be extremely fast - you should be able to > plot arrays 10 times this big with good performance. From your > description "It does first draw a default plot ..and then overplot on > it for each subplot." it sounds like you may have interactive mode > turned on. This would kill your performance in a case like this, > because the entire figure would be redrawn with the update of every > single plotting command. See > http://matplotlib.sourceforge.net/interactive.html and > http://matplotlib.sourceforge.net/faq.html#SHOW . > > To definitively determine what mode you are in, run your script with > > > python simple_plot.py --verbose-helpful > > and verify that 'interactive is False'. Fernando Perez's ipython has > support for running scripts from the interactive shell, turning off > interactive mode for the duration of the run, and then restoring it. > I wondered the same thing and mentioned that to him privately (in effect you are doing n*(n-1)/2 plots instead of n). But that made me wonder whether or not there was a need for some sort of switch that delayed any update for just this case where one is looping over many plots (say you wrote a ploting function that did this that you want to run in interactive mode, and you wanted to use basic plotting functions like plot). Is there a simple mechanism to turn off interactive mode temporarily within the function and restore it at the end? If not, could it be added? (akin to the hold() function) Perry |
|
From: John H. <jdh...@ac...> - 2004-12-11 06:01:04
|
>>>>> "Perry" == Perry Greenfield <pe...@st...> writes:
Perry> But that made me wonder whether or not there was a need for
Perry> some sort of switch that delayed any update for just this
Perry> case where one is looping over many plots (say you wrote a
Perry> ploting function that did this that you want to run in
Perry> interactive mode, and you wanted to use basic plotting
Perry> functions like plot). Is there a simple mechanism to turn
Perry> off interactive mode temporarily within the function and
Perry> restore it at the end? If not, could it be added? (akin to
Perry> the hold() function)
Aside from the aforementioned "run" mode of ipython, which does just
this, the basic incantation is
>>> from matplotlib import interactive, is_interactive
>>> b = is_interactive() # store the current interactive state
>>> plot(blah, blah) # make some plots
>>> interactive(False) # turn interactive off
>>> for i in arange(1e4096): plot(arange(i), arange(i)**2) # don't try this at home
>>> interactive(b) # restore previous interactive state
Basically, this is what ipython does. This is wrapped into a single
function "run", called like
>>> x = 1 # some fluff
>>> run ~/myexamples/simple_demo.py # turn interactive off for run
>>> x = 2 # interactive setting is restored
But of course, you can use the interactive / is_interactive functions
in any script or interactive session.
To make this more accessible, perhaps we should add an interactive (or
update) kwarg to plot and friends, in the same vein that we discussed
a kwarg for hold, so you can easily do things like
plot(x, y, hold=False) # add plot, clearing previous
plot(x, y, update=False) # add plot but do not update
But the question arises, does the additional complexity in the
matplotlib internals required to support this justify the savings for
the occasional user who would otherwise have to type a couple of extra
lines?
JDH
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X