matplotlib-devel Mailing List for matplotlib

I've been working on an application that uses matplotlib as its
plotting library, and I've been noticing a steady decrease in
performance over time. I figured out the cause as coming from the
matplotlib SpanSelector widget - I had to create a new widget every
time the axes were cleared, as the SpanSelector would not draw
correctly afterwards. The event processing calls were still being
made though, so over time I collected hundreds of SpanSelectors,
rendering the app unusable after a while. This patch adds a new_axes
method to the SpanSelector that can be called to simply re-assign the
spanselector to a new axes so I only need one. Below is a diff
against the latest svn.
Also, is it better practice to submit patches like this to this
mailing list, or the sourceforge tracker? I've seen some people do
both, and it seems like the tracker isn't kept up very well...
Index: lib/matplotlib/widgets.py
===================================================================
--- lib/matplotlib/widgets.py	(revision 4950)
+++ lib/matplotlib/widgets.py	(working copy)
@@ -829,12 +829,9 @@
 self.ax = ax
 self.visible = True
- self.canvas = ax.figure.canvas
- self.canvas.mpl_connect('motion_notify_event', self.onmove)
- self.canvas.mpl_connect('button_press_event', self.press)
- self.canvas.mpl_connect('button_release_event', self.release)
- self.canvas.mpl_connect('draw_event', self.update_background)
-
+ self.cids=[]
+ self.canvas = None
+
 self.rect = None
 self.background = None
@@ -847,12 +844,30 @@
 # Needed when dragging out of axes
 self.buttonDown = False
 self.prev = (0, 0)
+
+ self.new_axes(ax)
+
+ def new_axes(self,ax):
+ self.ax = ax
+ if self.canvas is not ax.figure.canvas:
+		for i,cid in enumerate(self.cids[:]):
+		 try:
+		 self.canvas.mpl_disconnect(cid)
+		 except: #if the old canvas is dead or anything else unexpected
+		 pass
+		 self.cids.remove(cid)
+		
+		self.canvas = ax.figure.canvas
+		self.cids.append(self.canvas.mpl_connect('motion_notify_event', self.onmove))
+		self.cids.append(self.canvas.mpl_connect('button_press_event', self.press))
+		self.cids.append(self.canvas.mpl_connect('button_release_event',
self.release))
+		self.cids.append(self.canvas.mpl_connect('draw_event',
self.update_background))
 if self.direction == 'horizontal':
- trans = blended_transform_factory(self.ax.transData,
self.ax.transAxes)
+ trans = blend_xy_sep_transform(self.ax.transData,
self.ax.transAxes)
 w,h = 0,1
 else:
- trans = blended_transform_factory(self.ax.transAxes,
self.ax.transData)
+ trans = blend_xy_sep_transform(self.ax.transAxes,
self.ax.transData)
 w,h = 1,0
 self.rect = Rectangle( (0,0), w, h,
 transform=trans,

I have been having some very strange import problems in Mayavi2.
Basically the namespace packages in enthought did not import properly. I
finally narrowed them down to the fact that I had installed matplotlib
using setuptools, and that in the beginning of my easy_install.pth file I
had /home/varoquau/dev/matplotlib/trunk/matplotlib/lib, in which there is
an enthought directory. This breaks the setuptools namespace packages
magic. The short term solution is to move this line at the end of the
easy_install.pth. I am however worried: this is a major weakness of
setuptools namespace packages, and it will happen to other people.
I have no solution (sorry) but this problem needs to be addressed.
Cheers,
Gaël

On Sun, Feb 10, 2008 at 09:41:34AM -0600, John Hunter wrote:
> It is likely we will support enthought traits for matplotlob figures
> in the not too distant future -- at that point, many of the plot
> elements will have UI dialogs for customization, at least for certain
> backends (Qt and WX most likely)
I am so happy to hear you say this. With Traits in MPL, it would be
possible to build an interactive plotting application based around
envisage, using other envisage plugins for a python shell and an array
editor.
Moreover, if the MPL plugin is well-designed, it could be used in other
envisage application.
There still is work to do, but I can see the pieces of the puzzle coming
together.
Cheers,
Gaël

John Hunter wrote:
> On Feb 10, 2008 7:32 AM, Neal Becker
> <ndb...@gm...> wrote:
>> The available plotting in pylab is good, but could be a lot better. I've
>> used grace (xmgrace) for years and it's great. After bringing up the
>> plot, I can interactively modify it in all kinds of ways.
> 
> Well, you can certainly modify a matplotlib plot interactively, but
> you have to use the plotting methods. Do you mean with a GUI?
> 
Yes, I meant with a gui. Not just a minimal gui, but a full-featured one.
> Chaco has very good support for using a GUI to modify plot elements,
> as does veusz, though they ack some of the features matplotlib
> provides.
I'm curious about chaco. Looks like no egg for me. Fedora8 x86-64.

On Feb 10, 2008 7:32 AM, Neal Becker <ndb...@gm...> wrote:
> The available plotting in pylab is good, but could be a lot better. I've
> used grace (xmgrace) for years and it's great. After bringing up the plot,
> I can interactively modify it in all kinds of ways.
Well, you can certainly modify a matplotlib plot interactively, but
you have to use the plotting methods. Do you mean with a GUI?
Chaco has very good support for using a GUI to modify plot elements,
as does veusz, though they ack some of the features matplotlib
provides.
It is likely we will support enthought traits for matplotlob figures
in the not too distant future -- at that point, many of the plot
elements will have UI dialogs for customization, at least for certain
backends (Qt and WX most likely)
JDH

The available plotting in pylab is good, but could be a lot better. I've
used grace (xmgrace) for years and it's great. After bringing up the plot,
I can interactively modify it in all kinds of ways.
Any thoughts on a good package to use with pylab? (I know I can easily
enough get pylab to use grace. One problem, though, is that grace is
pretty old now. It is based on Motif. I'd love to see it ported to say,
Qt, but I'm sure that's a huge effort)

I noticed while making some plots with upper bound error bars that
whenever Axes.errorbars is called with any of the errorbars chosen as
upper or lower bounds, that the color cycle was off, skipping over 2
colors each time another errorbar plot was made (e.g. the first would
be green and the second would be cyan instead of blue,green,red,cyan).
Looking into the axes class, it appears that if you don't specify a
color and want the markers to be drawn over the errorbars, the color
cycle has already been skipped over one because of calls to draw the
markers into the plot. The solution is to change all the lines that
say " ls='None' " in the errorbar method to instead say " ls='k' " -
this will prevent those calls from cycling the colors, and hence only
the call to actually draw the markers will do so. Can this patch be
committed to svn?