matplotlib-devel Mailing List for matplotlib

On Mon, Jun 9, 2008 at 3:22 PM, Dave Peterson <dpe...@en...> wrote:
> Yes, he and I sat together in a sprint room at Scipy and refactored Traits
> code (and everything else using setuptools and namespace packages) until we
> removed it all, taking timing runs each step of the way. I'd actually be
> surprised if Fernando was using NSF mounts during this effort, but I don't
> remember asking. I do remember him pointing out how bad it *would* be for
> anyone using network drives to suffer through some of the API call counts we
> saw when using namespace packages.
You are correct: I was NOT using an NFS mount, it was all done on my
(slow) laptop. We were seeing enormous numbers (tens of thousands) of
disc/directory access calls that I was very worried about if said disk
was on NFS. Part of this was due to the fact that back at work in
Colorado, I *did* have my $HOME on NFS and I'd recalled seeing some
slowness here and there, but I never went back to repeat our profiling
exercise at work, so I can't provide numbers on that.
Cheers,
f

On Mon, Jun 9, 2008 at 10:16 AM, Eric Firing <ef...@ha...> wrote:
> Please try now, with r5435 or later. There is still the underlying
> puzzle to be solved before all this can be cleaned up, but I think the
> basic functionality is back.
Eric: in Shell,py, around line 1167, you'll find this code:
 backends = {'gthread' : 'GTKAgg',
 'wthread' : 'WXAgg',
 'qthread' : 'QtAgg',
 'q4thread' :'Qt4Agg',
 'tkthread' :'TkAgg',
 }
That is used to SET the rcParams['backend'] value. I don't know if
that can cause issues.
But more importantly, I think the problem you see comes from this code
(just a bit later in the same file):
 else:
 backend = matplotlib.rcParams['backend']
 if backend.startswith('GTK'):
 th_mode = 'gthread'
 elif backend.startswith('WX'):
 th_mode = 'wthread'
 elif backend.startswith('Qt4'):
 th_mode = 'q4thread'
 elif backend.startswith('Qt'):
 th_mode = 'qthread'
 else:
 # Any other backend, use plain Tk
 th_mode = 'tkthread'
 return mpl_shell[th_mode]
IPython does an explicit check on the names of the backends with that
exact capitalization. I could add a .lower() call to the line that
starts:
 backend = matplotlib.rcParams['backend'].lower()
and change the .startswith() calls to do all lowercase checks. Could
you see if that helps? That would make the fix backwards compatible.
Cheers,
f

On Monday 09 June 2008 6:22:28 pm Dave Peterson wrote:
> I didn't intend to start up the root cause discussion again. :-) I only
> wanted to point out that I hadn't heard of anyone working on improving
> whatever performance problems exist / existed.
I just wanted to avoid having a misperception turn into conventional wisdom. 
We see that enough in political discourse.

Darren Dale wrote:
> On Monday 09 June 2008 04:04:47 pm Dave Peterson wrote:
> 
>> Eric Firing wrote:
>> 
>>> Dave Peterson wrote:
>>> 
>>>> That said, given the upcoming release of Traits 3 this situation may
>>>> get a little crazier. T2 and T3 are not fully api compatible, though
>>>> they are very close. So I suspect version numbers are going to play
>>>> a larger role in the future. Is there anything we can do in the T3
>>>> release to make resolution of this upcoming issue easier to deal with
>>>> for the matplotlib team? One point probably worth mentioning is
>>>> that, IIRC, we currently rely on T3 being installed with egg
>>>> meta-data in order to determine an accurate version number.
>>>> 
>>> Whether, or to what extent, mpl starts depending on traits is still
>>> open; but if we do depend on it, I think we should simply require T3
>>> as an external dependency. If that requires some slight modifications
>>> of Darren's code, which was written for T2, I expect the changes will
>>> be easy.
>>> 
>
> I think T2->T3 would not be a difficult transition for us. It may not even 
> require any modifications, I seem to remember the traited config stuff just 
> worked with traits3 last time I tried it, I just dont remember when I tried 
> it last.
> 
Yes, the API breaks are not large at all. They're actually fairly 
small, the bulk of the effort on T3 was behind the scenes and added 
functionality. But there are some there so it may not be clear sailing 
for everyone.
>>> Three questions:
>>>
>>> 1) To what extent would the range of T3 eggs cover the various
>>> platforms on which people run mpl?
>>> 
>> Not quite sure on this one as I don't know what platforms are most used
>> by mpl. What I can say is that we've worked very hard to minimize the
>> dependencies Traits has on other things in order to make it as easy as
>> possible for people to install. We'll definitely be uploading a source
>> tarball, which should meet most people's needs, and a Windows binary
>> (since not all users there have a c compiler.) We may or may not put up
>> OS X, and a couple linux distribution, binaries.
>>
>> 
>>> 2) For uncovered cases, should T3 be easy to build and install?
>>> 
>> T3 proper needs a c compiler, gcc seems to work fine. TraitsGUI and the
>> backend projects seem to be pure-python though clearly you'll need libs
>> for the chosen backend.
>>
>> 
>>> 3) My recollection is that setuptools was determined to be causing a
>>> hit to the startup time, and mpl is already sluggish in starting up.
>>> Is there any more insight or progress on this front? Is there a way
>>> to use traits in mpl without increasing the startup time?
>>> 
>> I'm not sure it was setuptools' egg features that were the problem so
>> much as I thought it was the use of namespace packaging we have embedded
>> all over in ETS. I don't see any significant efforts underway at this
>> time that are trying to speed this up, but perhaps I'm just uninformed
>> about any such efforts. I don't see anything on the horizon that would
>> let us remove this from the ETS projects either. The end result is I
>> don't see any way mpl could work around this and still treat Traits as
>> an external dependency.
>> 
>
> Fernando saw a big performance hit due to namespace packaging, but I never saw 
> it. I think we concluded that the presence of large NFS mounts were causing 
> the performance hit in namespace packages that Fernando reported at Scipy 
> last year (Dave, was it you who worked with him?).
> 
Yes, he and I sat together in a sprint room at Scipy and refactored 
Traits code (and everything else using setuptools and namespace 
packages) until we removed it all, taking timing runs each step of the 
way. I'd actually be surprised if Fernando was using NSF mounts during 
this effort, but I don't remember asking. I do remember him pointing 
out how bad it *would* be for anyone using network drives to suffer 
through some of the API call counts we saw when using namespace packages.
> I did some profiling a while back also, after we added traits to the mpl 
> codebase and stripped out the namespace packaging. We still saw something 
> like a 30% performance hit, which I tracked back to regular expressions being 
> compiled in traits and in configobj. See:
> http://thread.gmane.org/gmane.comp.python.enthought.devel/10908/focus=10989
> 
I didn't intend to start up the root cause discussion again. :-) I only 
wanted to point out that I hadn't heard of anyone working on improving 
whatever performance problems exist / existed.
-- Dave
> Darren
>
> 

On Monday 09 June 2008 04:04:47 pm Dave Peterson wrote:
> Eric Firing wrote:
> > Dave Peterson wrote:
> >> That said, given the upcoming release of Traits 3 this situation may
> >> get a little crazier. T2 and T3 are not fully api compatible, though
> >> they are very close. So I suspect version numbers are going to play
> >> a larger role in the future. Is there anything we can do in the T3
> >> release to make resolution of this upcoming issue easier to deal with
> >> for the matplotlib team? One point probably worth mentioning is
> >> that, IIRC, we currently rely on T3 being installed with egg
> >> meta-data in order to determine an accurate version number.
> >
> > Whether, or to what extent, mpl starts depending on traits is still
> > open; but if we do depend on it, I think we should simply require T3
> > as an external dependency. If that requires some slight modifications
> > of Darren's code, which was written for T2, I expect the changes will
> > be easy.
I think T2->T3 would not be a difficult transition for us. It may not even 
require any modifications, I seem to remember the traited config stuff just 
worked with traits3 last time I tried it, I just dont remember when I tried 
it last.
> > Three questions:
> >
> > 1) To what extent would the range of T3 eggs cover the various
> > platforms on which people run mpl?
>
> Not quite sure on this one as I don't know what platforms are most used
> by mpl. What I can say is that we've worked very hard to minimize the
> dependencies Traits has on other things in order to make it as easy as
> possible for people to install. We'll definitely be uploading a source
> tarball, which should meet most people's needs, and a Windows binary
> (since not all users there have a c compiler.) We may or may not put up
> OS X, and a couple linux distribution, binaries.
>
> > 2) For uncovered cases, should T3 be easy to build and install?
>
> T3 proper needs a c compiler, gcc seems to work fine. TraitsGUI and the
> backend projects seem to be pure-python though clearly you'll need libs
> for the chosen backend.
>
> > 3) My recollection is that setuptools was determined to be causing a
> > hit to the startup time, and mpl is already sluggish in starting up.
> > Is there any more insight or progress on this front? Is there a way
> > to use traits in mpl without increasing the startup time?
>
> I'm not sure it was setuptools' egg features that were the problem so
> much as I thought it was the use of namespace packaging we have embedded
> all over in ETS. I don't see any significant efforts underway at this
> time that are trying to speed this up, but perhaps I'm just uninformed
> about any such efforts. I don't see anything on the horizon that would
> let us remove this from the ETS projects either. The end result is I
> don't see any way mpl could work around this and still treat Traits as
> an external dependency.
Fernando saw a big performance hit due to namespace packaging, but I never saw 
it. I think we concluded that the presence of large NFS mounts were causing 
the performance hit in namespace packages that Fernando reported at Scipy 
last year (Dave, was it you who worked with him?).
I did some profiling a while back also, after we added traits to the mpl 
codebase and stripped out the namespace packaging. We still saw something 
like a 30% performance hit, which I tracked back to regular expressions being 
compiled in traits and in configobj. See:
http://thread.gmane.org/gmane.comp.python.enthought.devel/10908/focus=10989
Darren

On Sat, Jun 7, 2008 at 4:36 AM, Nils Wagner
<nw...@ia...> wrote:
> Hi all,
>
> I have some trouble with matplotlib's svn version.
> Any pointer would be appreciated.
> self.canvas.SetInitialSize(wx.Size(fig.bbox.width,
> fig.bbox.height))
> AttributeError: 'FigureCanvasWxAgg' object has no
> attribute 'SetInitialSize'
This came from Stan's patch to fix figure sizing in wx. Nils, could
you report your wx version, and Stan, could you see if there is a
version problem in the SetInitialSize call?
Thanks,
JDH

Eric Firing wrote:
> Dave Peterson wrote:
>
>> That said, given the upcoming release of Traits 3 this situation may 
>> get a little crazier. T2 and T3 are not fully api compatible, though 
>> they are very close. So I suspect version numbers are going to play 
>> a larger role in the future. Is there anything we can do in the T3 
>> release to make resolution of this upcoming issue easier to deal with 
>> for the matplotlib team? One point probably worth mentioning is 
>> that, IIRC, we currently rely on T3 being installed with egg 
>> meta-data in order to determine an accurate version number.
>
> Whether, or to what extent, mpl starts depending on traits is still 
> open; but if we do depend on it, I think we should simply require T3 
> as an external dependency. If that requires some slight modifications 
> of Darren's code, which was written for T2, I expect the changes will 
> be easy.
>
> Three questions:
>
> 1) To what extent would the range of T3 eggs cover the various 
> platforms on which people run mpl?
Not quite sure on this one as I don't know what platforms are most used 
by mpl. What I can say is that we've worked very hard to minimize the 
dependencies Traits has on other things in order to make it as easy as 
possible for people to install. We'll definitely be uploading a source 
tarball, which should meet most people's needs, and a Windows binary 
(since not all users there have a c compiler.) We may or may not put up 
OS X, and a couple linux distribution, binaries.
> 2) For uncovered cases, should T3 be easy to build and install?
T3 proper needs a c compiler, gcc seems to work fine. TraitsGUI and the 
backend projects seem to be pure-python though clearly you'll need libs 
for the chosen backend.
> 3) My recollection is that setuptools was determined to be causing a 
> hit to the startup time, and mpl is already sluggish in starting up. 
> Is there any more insight or progress on this front? Is there a way 
> to use traits in mpl without increasing the startup time?
I'm not sure it was setuptools' egg features that were the problem so 
much as I thought it was the use of namespace packaging we have embedded 
all over in ETS. I don't see any significant efforts underway at this 
time that are trying to speed this up, but perhaps I'm just uninformed 
about any such efforts. I don't see anything on the horizon that would 
let us remove this from the ETS projects either. The end result is I 
don't see any way mpl could work around this and still treat Traits as 
an external dependency. 
-- Dave

Dave Peterson wrote:
> That said, given the upcoming release of Traits 3 this situation may get 
> a little crazier. T2 and T3 are not fully api compatible, though they 
> are very close. So I suspect version numbers are going to play a 
> larger role in the future. Is there anything we can do in the T3 
> release to make resolution of this upcoming issue easier to deal with 
> for the matplotlib team? One point probably worth mentioning is that, 
> IIRC, we currently rely on T3 being installed with egg meta-data in 
> order to determine an accurate version number.
Whether, or to what extent, mpl starts depending on traits is still 
open; but if we do depend on it, I think we should simply require T3 as 
an external dependency. If that requires some slight modifications of 
Darren's code, which was written for T2, I expect the changes will be easy.
Three questions:
1) To what extent would the range of T3 eggs cover the various platforms 
 on which people run mpl?
2) For uncovered cases, should T3 be easy to build and install?
3) My recollection is that setuptools was determined to be causing a hit 
to the startup time, and mpl is already sluggish in starting up. Is 
there any more insight or progress on this front? Is there a way to use 
traits in mpl without increasing the startup time?
I gather from the lists that we are still not out of the woods with 
respect to making mpl (and scipy, even more) easy to install, and 
ideally easy to build from svn, for nearly all users; I would not want 
to see us start depending on traits if this will make the present bad 
situation worse.
Thanks.
Eric

Gael Varoquaux wrote:
> On Mon, Jun 09, 2008 at 12:04:58PM -0400, Darren Dale wrote:
> 
>> Gael, maybe the following situation caused the trouble:
>> 
>
> 
>> 1) user downloads mpl source
>> 2) builds matplotlib - traits now exists in the temproary build directory
>> 3) installs enthought traits
>> 4) installs matplotlib - traits would not have been built in this case, its 
>> already installed on the system, but it still exists in the build directory 
>> and gets installed anyway.
>> 
>
> Actually, after looking at the code and thinking a bit more, I think the
> problem might simply be with different version of traits installed in
> different directories in the sys.path, with Python's import mechanism
> picking up the MPL-installed one, rather then the user-installed one.
> Tricky problems that I see more and more happenning.
>
> But I don't have an example box to test this hypothesis, so we are still
> clueless.
> 
In my experience, the current method really only falls down for those 
trying to publish binary distributions who don't realize the potential 
consequences of this build-time detection, or that there is even a 
decision being made there about the content of what is being built. 
Say, perhaps those building EPD. :-) Luckily, once you know what is 
going on during the build, it's a pretty easy problem to solve.
That said, given the upcoming release of Traits 3 this situation may get 
a little crazier. T2 and T3 are not fully api compatible, though they 
are very close. So I suspect version numbers are going to play a 
larger role in the future. Is there anything we can do in the T3 
release to make resolution of this upcoming issue easier to deal with 
for the matplotlib team? One point probably worth mentioning is that, 
IIRC, we currently rely on T3 being installed with egg meta-data in 
order to determine an accurate version number.
-- Dave

Darren Dale wrote:
> I think we would rather make traits an external dependency, if it could be 
> easily installed as a separate package by a novice python user. Would it be 
> possible for http://code.enthought.com/projects/traits/ to list specific 
> instructions and links to the downloads? Or to list traits on the Python 
> Package Index?
> 
We have now scheduled resources to finish the ETS refactoring that will 
allow us to release Traits 3, which means publishing it into PyPI. The 
effort won't start until next week at the earliest though. Even though 
I'm a bit gun-shy about doing this, I'd forecast we have Traits 3.0 
officially released and on PyPI by the end of June, perhaps a week into 
July.
-- Dave

On 2008年6月09日 07:41:05 -1000
 Eric Firing <ef...@ha...> wrote:
> Nils Wagner wrote:
>> Hi Eric,
>> 
>> I have still some trouble with the following example 
>>taken from openopt
>> 
>> 
>> /usr/bin/python -i nlp_3.py
>> starting solver ipopt (license: CPL) with problem nlp3
>> [PyIPOPT] Ipopt will use Hessian approximation.
>> [PyIPOPT] nele_hess is 0
>> iter objFunVal log10(maxResidual)
>> 0 -1.640e+02 0.81
>> Traceback (most recent call last):
>> File "nlp_3.py", line 65, in ?
>> r = p.solve(solver)
>> File 
>> "/usr/lib/python2.4/site-packages/scikits/openopt/Kernel/BaseProblem.py", 
>> line 236, in solve
>> return runProbSolver(self, solvers, *args, **kwargs)
>> File 
>> "/usr/lib/python2.4/site-packages/scikits/openopt/Kernel/runProbSolver.py", 
>> line 219, in runProbSolver
>> solver(p)
>> File 
>> "/usr/lib/python2.4/site-packages/scikits/openopt/solvers/CoinOr/ipopt_oo.py", 
>> line 70, in __solver__
>> p.iterfcn(p.x0)
>> File 
>> "/usr/lib/python2.4/site-packages/scikits/openopt/Kernel/BaseProblem.py", 
>> line 57, in <lambda>
>> self.iterfcn = lambda *args: ooIter(self, *args)# 
>>this parameter is 
>> only for OpenOpt developers, not common users
>> File 
>> "/usr/lib/python2.4/site-packages/scikits/openopt/Kernel/ooIter.py", 
>> line 78, in ooIter
>> for df in p.graphics.drawFuncs: df(p)
>> File 
>> "/usr/lib/python2.4/site-packages/scikits/openopt/Kernel/ooGraphics.py", 
>> line 127, in oodraw
>> if self.nSubPlots>1: pylab.subplot(self.nSubPlots, 
>>1, 1)
>> File 
>>"/usr/lib/python2.4/site-packages/matplotlib/pyplot.py", 
>>line 
>> 519, in subplot
>> fig = gcf()
>> File 
>>"/usr/lib/python2.4/site-packages/matplotlib/pyplot.py", 
>>line 
>> 210, in gcf
>> return figure()
>> File 
>>"/usr/lib/python2.4/site-packages/matplotlib/pyplot.py", 
>>line 
>> 195, in figure
>> FigureClass=FigureClass,
>> File 
>> "/usr/lib/python2.4/site-packages/matplotlib/backends/backend_wxagg.py", 
>> line 119, in new_figure_manager
>> frame = FigureFrameWxAgg(num, fig)
>> File 
>> "/usr/lib/python2.4/site-packages/matplotlib/backends/backend_wx.py", 
>> line 1237, in __init__
>> self.canvas.SetInitialSize(wx.Size(fig.bbox.width, 
>>fig.bbox.height))
>> AttributeError: 'FigureCanvasWxAgg' object has no 
>>attribute 
>> 'SetInitialSize'
>> 
>> Any idea ?
> 
> No clue. When did it stop working?
> 
> efiring@manini:~/programs/py/mpl/mpl_trunk/lib/matplotlib$ 
>rgrep SetInitialSize --include '*.py' .
> ./backends/backend_wx.py: 
>self.canvas.SetInitialSize(wx.Size(fig.bbox.width, 
>fig.bbox.height))
> ./backends/backend_wx.py: 
>self.canvas.SetInitialSize(wx.Size(width, height))
> 
> I can't find anything in the code that defines 
>SetInitialSize.
> 
I didn't check the example nlp_3.py (from openopt) 
regularly. So I can't tell you when it stopped.
As a workaround I have used another backend in my
matplotlibrc
#### CONFIGURATION BEGINS HERE
# the default backend; one of GTK GTKAgg GTKCairo FltkAgg 
QtAgg TkAgg
# Agg Cairo GD GDK Paint PS PDF SVG Template
#backend : WXAgg
backend : TkAgg
 
Cheers,
 Nils

Andrew Straw wrote:
> Hi Eric,
> 
> show() isn't bringing up my plots with r5430 in normal scripts (i.e. not
> using IPython).
Andrew,
Please try now, with r5435 or later. There is still the underlying 
puzzle to be solved before all this can be cleaned up, but I think the 
basic functionality is back.
Eric
> 
> -Andrew
> 
> Eric Firing wrote:
>> While investigating a bug pointed out by Andrew (and one that I had 
>> introduced some time ago) I found to my horror that I had also caused 
>> another bug: interactive plotting was not working with ipython -pylab. 
>> I backed out part of r5420, and that fixed the problem. This temporary 
>> fix is to restore the mixed case backend names in the interactive_bk 
>> list that is now set in rcsetup.py and imported by backends/__init__.py.
>>
>> I am baffled as to why this is needed at present; I have not been able 
>> to figure out why ipython threading seems to get confused when that list 
>> has lower case names for gtkagg, qtagg, and wxagg, but not for tkagg or 
>> qt4agg. I don't see anywhere in either the ipython or the mpl code that 
>> should care about the case of the names in that list, now that I have 
>> ensured that comparisons against backend names in mpl (everywhere I 
>> could find them--maybe I missed on) are case-insensitive, and 
>> get_backend() returns only lower case. rcParams['backend'] can still 
>> have mixed case, however.
>>
>> Any suggestions as to what I am missing or where to look?
>>
>> Related question: I just noticed that there is also a config/rcsetup.py. 
>> Is there any reason why there has to be so much duplication (and now 
>> gradual divergence) between this and the regular rcsetup.py? Is there 
>> any reason the traits config system can't use the regular version, maybe 
>> with some changes merged in?
>>
>> Eric
>>
>> -------------------------------------------------------------------------
>> Check out the new SourceForge.net Marketplace.
>> It's the best place to buy or sell services for
>> just about anything Open Source.
>> http://sourceforge.net/services/buy/index.php
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> 
> 

On Monday 09 June 2008 11:48:30 am John Hunter wrote:
> Those of you who have been building the docs have probably seen the
> inscrutable table warnings coming from sphinx. I just got a clue
> where these are coming from. Look at the table formatting from this
> ipython session (in case your email client doesn't handle monospace
> right, the table border at the top is not indented right. Darren,
> I'll let you take this -- somewhere in the dedent/kwarg table
> interpolation, some spacing is getting botched.
Thanks. I hadn't noticed it before, and had to blow away the build/ to see the 
error. The artist.kwdocd['Patch'] at the top of patches.py needed a blank 
line above and below the table, its fixed now.

On Mon, Jun 9, 2008 at 11:45 AM, Gregor Thalhammer
>
> If I understood it correctly, Agg (i.e., span_image_resample_*) already
> exactly behaves like you proposed. It resamples the image if the scaling is
> less than 1, otherwise it interpolates.
> I am not an Agg expert. The documentation of Agg is not very exhaustive. I
> took it from one of the demos. span_image_resample_rgba_affine seems to be
> faster than span_image_resample_rgba, but it supports affine but no
> perspective transformations. If I understood it correctly, matplotlib only
> uses image translation and scaling, not even rotation or shearing. All this
> is covered by span_image_resample_rgba_affine.
OK, all this sounds reasonable. I've committed the changes to the
trunk. Thanks for the explanation and the patch!
JDH

John Hunter schrieb:
> On Mon, Jun 9, 2008 at 10:18 AM,
>
> 
>> I attached a patch against the current svn version that adds a 'resample'
>> argument to imshow. Additionally, this patch supports a 'image.resample'
>> entry in the rc file. Setting this to false (default), the behaviour is
>> unchanged.
>> 
>
> Hi Gregor -- thanks for sending this. It's something I was aware of
> in agg but never got around to exposing. I wonder if the
> resample=True|False is the right approach. It might be nice for
> imshow to have an 'auto' mode to either resample or interpolate
> depending on the image dimensions w/ respect to the destination size.
> Ie, if we are displaying the full image into a small destination,
> 'auto' would default to resample. If we zoom in sufficiently, the
> image might be best displayed with interpolation. Is this something
> you think would be worthwhile and would you like to work on support
> for this?
> 
If I understood it correctly, Agg (i.e., span_image_resample_*) already 
exactly behaves like you proposed. It resamples the image if the scaling 
is less than 1, otherwise it interpolates.
> Also,l I notice the patch exposes span_image_resample_rgba_affine but not
> span_image_resample_rgba which takes an interpolator template
> argument. I know very little about this area, but was this a
> conscious choice or one of expediency? Can you explain the rational?
>
> 
I am not an Agg expert. The documentation of Agg is not very exhaustive. 
I took it from one of the demos. span_image_resample_rgba_affine seems 
to be faster than span_image_resample_rgba, but it supports affine but 
no perspective transformations. If I understood it correctly, matplotlib 
only uses image translation and scaling, not even rotation or shearing. 
All this is covered by span_image_resample_rgba_affine.
Gregor

Andrew Straw wrote:
> Hi Eric,
> 
> show() isn't bringing up my plots with r5430 in normal scripts (i.e. not
> using IPython).
Sure enough. It seems that in the process of bisecting the svn versions 
to track down this problem and the original one you reported, things got 
mixed up in my directory, so that what worked on what I thought was the 
svn head was actually working on some mongrel. After a fresh checkout 
with clean build and install, I find that neither plain show nor ipython 
-pylab is working.
Back to the drawing board. I really would like to get everything 
working with complete case-insensitivity, and lower-case defaults, for 
the backend names. There is no reason one should have to remember that 
it is TkAgg, not TKAgg, but GTKAgg, not GtkAgg.
Eric
> 
> -Andrew
> 
> Eric Firing wrote:
>> While investigating a bug pointed out by Andrew (and one that I had 
>> introduced some time ago) I found to my horror that I had also caused 
>> another bug: interactive plotting was not working with ipython -pylab. 
>> I backed out part of r5420, and that fixed the problem. This temporary 
>> fix is to restore the mixed case backend names in the interactive_bk 
>> list that is now set in rcsetup.py and imported by backends/__init__.py.
>>
>> I am baffled as to why this is needed at present; I have not been able 
>> to figure out why ipython threading seems to get confused when that list 
>> has lower case names for gtkagg, qtagg, and wxagg, but not for tkagg or 
>> qt4agg. I don't see anywhere in either the ipython or the mpl code that 
>> should care about the case of the names in that list, now that I have 
>> ensured that comparisons against backend names in mpl (everywhere I 
>> could find them--maybe I missed on) are case-insensitive, and 
>> get_backend() returns only lower case. rcParams['backend'] can still 
>> have mixed case, however.
>>
>> Any suggestions as to what I am missing or where to look?
>>
>> Related question: I just noticed that there is also a config/rcsetup.py. 
>> Is there any reason why there has to be so much duplication (and now 
>> gradual divergence) between this and the regular rcsetup.py? Is there 
>> any reason the traits config system can't use the regular version, maybe 
>> with some changes merged in?
>>
>> Eric
>>
>> -------------------------------------------------------------------------
>> Check out the new SourceForge.net Marketplace.
>> It's the best place to buy or sell services for
>> just about anything Open Source.
>> http://sourceforge.net/services/buy/index.php
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> 
> 

On Mon, Jun 09, 2008 at 06:41:08AM -0400, Darren Dale wrote:
> I think we would rather make traits an external dependency, if it could be 
> easily installed as a separate package by a novice python user. Would it be 
> possible for http://code.enthought.com/projects/traits/ to list specific 
> instructions and links to the downloads? Or to list traits on the Python 
> Package Index?
If I get things correctly, having traits on PyPI is planned for the
version 3 release, which should happen when the guys at Enthought find
time to make it happen. However I cannot speak for them, as I am not
employed by Enthought, sitting in Austin (Yet !). I will also be very
happy the day this happens.
Gaël

On Mon, Jun 09, 2008 at 12:04:58PM -0400, Darren Dale wrote:
> Gael, maybe the following situation caused the trouble:
> 1) user downloads mpl source
> 2) builds matplotlib - traits now exists in the temproary build directory
> 3) installs enthought traits
> 4) installs matplotlib - traits would not have been built in this case, its 
> already installed on the system, but it still exists in the build directory 
> and gets installed anyway.
Actually, after looking at the code and thinking a bit more, I think the
problem might simply be with different version of traits installed in
different directories in the sys.path, with Python's import mechanism
picking up the MPL-installed one, rather then the user-installed one.
Tricky problems that I see more and more happenning.
But I don't have an example box to test this hypothesis, so we are still
clueless.
Cheers,
Gaël

On Monday 09 June 2008 09:52:46 am John Hunter wrote:
> On Mon, Jun 9, 2008 at 5:41 AM, Darren Dale <dar...@co...> wrote:
> > I think we would rather make traits an external dependency, if it could
> > be easily installed as a separate package by a novice python user. Would
> > it be possible for http://code.enthought.com/projects/traits/ to list
> > specific instructions and links to the downloads? Or to list traits on
> > the Python Package Index?
>
> I also agree that we should not install a modified version of traits
> in the top level namespace. Let's disable all default installs of
> enthought traits until we work this out. We only need it for the
> optional rc config and so let's require that someone manually turn it
> on in setup.cfg if they want it. In particular, let's fix this before
> the next bugfix release. If we opt to depend on traits for the new
> rc, we will either need to require and external dependency, figure out
> a way to install a completely working and compatible version, or do
> the extra work to install it inside the matplotlib namespace. I
> prefer 1 or 3, but at this point I think whether we will migrate to
> the traited rc system is an open question so disabling is the right
> solution for now.
>
> Darren, can you take care of this?
Its done.
Gael, maybe the following situation caused the trouble:
1) user downloads mpl source
2) builds matplotlib - traits now exists in the temproary build directory
3) installs enthought traits
4) installs matplotlib - traits would not have been built in this case, its 
already installed on the system, but it still exists in the build directory 
and gets installed anyway.
Seems unlikely, but who knows.

Those of you who have been building the docs have probably seen the
inscrutable table warnings coming from sphinx. I just got a clue
where these are coming from. Look at the table formatting from this
ipython session (in case your email client doesn't handle monospace
right, the table border at the top is not indented right. Darren,
I'll let you take this -- somewhere in the dedent/kwarg table
interpolation, some spacing is getting botched.
JDH
class Arrow(Patch)
 | An arrow patch
 |
 | Method resolution order:
 | Arrow
 | Patch
 | matplotlib.artist.Artist
 | __builtin__.object
 |
 | Methods defined here:
 |
 | __init__(self, x, y, dx, dy, width=1.0, **kwargs)
 | Draws an arrow, starting at (x,y), direction and length
 | given by (dx,dy) the width of the arrow is scaled by width
 |
 | Valid kwargs are:
 | =================
==============================================
 | Property Description
 | ================= ==============================================
 | alpha float
 | animated [True | False]
 | antialiased or aa [True | False]
 | clip_box a matplotlib.transform.Bbox instance
 | clip_on [True | False]
 | edgecolor or ec any matplotlib color
 | facecolor or fc any matplotlib color
 | figure a matplotlib.figure.Figure instance
 | fill [True | False]
 | hatch unknown
 | label any string
 | linewidth or lw float
 | lod [True | False]
 | transform a matplotlib.transform transformation instance
 | visible [True | False]
 | zorder any number
 | ================= ==============================================

On Mon, Jun 9, 2008 at 10:18 AM,
> I attached a patch against the current svn version that adds a 'resample'
> argument to imshow. Additionally, this patch supports a 'image.resample'
> entry in the rc file. Setting this to false (default), the behaviour is
> unchanged.
Hi Gregor -- thanks for sending this. It's something I was aware of
in agg but never got around to exposing. I wonder if the
resample=True|False is the right approach. It might be nice for
imshow to have an 'auto' mode to either resample or interpolate
depending on the image dimensions w/ respect to the destination size.
Ie, if we are displaying the full image into a small destination,
'auto' would default to resample. If we zoom in sufficiently, the
image might be best displayed with interpolation. Is this something
you think would be worthwhile and would you like to work on support
for this?
Also,l I notice the patch exposes span_image_resample_rgba_affine but not
span_image_resample_rgba which takes an interpolator template
argument. I know very little about this area, but was this a
conscious choice or one of expediency? Can you explain the rational?
JDH

Dear developers,
matplotlib offers high quality interpolation filters which give 
excellent results if you scale up an image. However, for downscaling an 
image the results are worse. Depending on the precise scaling fine 
details (e.g., thin horizontal lines, single pixel points) disappear and 
aliasing effects are visible. After studying the source and the docs for 
Agg I figured out how to improve this. Agg provides all possibilities, 
just use them.
I attached a patch against the current svn version that adds a 
'resample' argument to imshow. Additionally, this patch supports a 
'image.resample' entry in the rc file. Setting this to false (default), 
the behaviour is unchanged.
I also attached a simple test script (test_imshow.py) to show the 
difference between image display with and without resampling. To see the 
difference it might be necessary to zoom out.
Gregor Thalhammer

Hi Eric,
show() isn't bringing up my plots with r5430 in normal scripts (i.e. not
using IPython).
-Andrew
Eric Firing wrote:
> While investigating a bug pointed out by Andrew (and one that I had 
> introduced some time ago) I found to my horror that I had also caused 
> another bug: interactive plotting was not working with ipython -pylab. 
> I backed out part of r5420, and that fixed the problem. This temporary 
> fix is to restore the mixed case backend names in the interactive_bk 
> list that is now set in rcsetup.py and imported by backends/__init__.py.
>
> I am baffled as to why this is needed at present; I have not been able 
> to figure out why ipython threading seems to get confused when that list 
> has lower case names for gtkagg, qtagg, and wxagg, but not for tkagg or 
> qt4agg. I don't see anywhere in either the ipython or the mpl code that 
> should care about the case of the names in that list, now that I have 
> ensured that comparisons against backend names in mpl (everywhere I 
> could find them--maybe I missed on) are case-insensitive, and 
> get_backend() returns only lower case. rcParams['backend'] can still 
> have mixed case, however.
>
> Any suggestions as to what I am missing or where to look?
>
> Related question: I just noticed that there is also a config/rcsetup.py. 
> Is there any reason why there has to be so much duplication (and now 
> gradual divergence) between this and the regular rcsetup.py? Is there 
> any reason the traits config system can't use the regular version, maybe 
> with some changes merged in?
>
> Eric
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 

On Mon, Jun 9, 2008 at 5:41 AM, Darren Dale <dar...@co...> wrote:
> I think we would rather make traits an external dependency, if it could be
> easily installed as a separate package by a novice python user. Would it be
> possible for http://code.enthought.com/projects/traits/ to list specific
> instructions and links to the downloads? Or to list traits on the Python
> Package Index?
I also agree that we should not install a modified version of traits
in the top level namespace. Let's disable all default installs of
enthought traits until we work this out. We only need it for the
optional rc config and so let's require that someone manually turn it
on in setup.cfg if they want it. In particular, let's fix this before
the next bugfix release. If we opt to depend on traits for the new
rc, we will either need to require and external dependency, figure out
a way to install a completely working and compatible version, or do
the extra work to install it inside the matplotlib namespace. I
prefer 1 or 3, but at this point I think whether we will migrate to
the traited rc system is an open question so disabling is the right
solution for now.
Darren, can you take care of this?
JDH

On Monday 09 June 2008 03:55:47 Eric Firing wrote:
> While investigating a bug pointed out by Andrew (and one that I had
> introduced some time ago) I found to my horror that I had also caused
> another bug: interactive plotting was not working with ipython -pylab.
> I backed out part of r5420, and that fixed the problem. This temporary
> fix is to restore the mixed case backend names in the interactive_bk
> list that is now set in rcsetup.py and imported by backends/__init__.py.
>
> I am baffled as to why this is needed at present; I have not been able
> to figure out why ipython threading seems to get confused when that list
> has lower case names for gtkagg, qtagg, and wxagg, but not for tkagg or
> qt4agg. I don't see anywhere in either the ipython or the mpl code that
> should care about the case of the names in that list, now that I have
> ensured that comparisons against backend names in mpl (everywhere I
> could find them--maybe I missed on) are case-insensitive, and
> get_backend() returns only lower case. rcParams['backend'] can still
> have mixed case, however.
>
> Any suggestions as to what I am missing or where to look?
>
> Related question: I just noticed that there is also a config/rcsetup.py.
> Is there any reason why there has to be so much duplication (and now
> gradual divergence) between this and the regular rcsetup.py? Is there
> any reason the traits config system can't use the regular version, maybe
> with some changes merged in?
We should probably discuss the future of TConfig in mpl at some point. Its been 
a while since I looked at it, but basically I was trying to isolate that code 
so it didnt creep into mpl until we were ready. There is lots of duplication 
in config, if you want to change it to import from rcsetup, its alright with 
me.