matplotlib-devel Mailing List for matplotlib

Hi Derek,

The slow speed for long paths like the one in your example was due to a limitation to Quartz itself. This was solved by breaking the path up into subpaths of up to 100 points. But you mentioned that releases before 1.2 were not slow (and I verified this with matplotlib 1.1.1), suggesting that something else is going on. Can you check which change between 1.1.1 and 1.2 is causing the slowdown for your example?

Best,
-Michiel.

--- On Fri, 4/12/13, Derek Homeier <de...@as...> wrote:

> From: Derek Homeier <de...@as...>
> Subject: Re: [matplotlib-devel] Planning for 1.3.0
> To: "mat...@li... list" <mat...@li...>
> Date: Friday, April 12, 2013, 5:16 PM
> On 11.04.2013, at 6:38PM, Michael
> Droettboom <md...@st...>
> wrote:
> 
> > Congrats to everyone on a successful 1.2.1 -- there was
> a relatively 
> > small influx of bug reports following it -- perhaps a
> sign of improving 
> > quality?
> 
> Thanks and congratulations to everyone involved as well;
> I've built 1.2.1 on MacOS X with fink for 
> Python2.6-3.2 without any failures in the test suite!
> I did run into a problem though that has actually existed
> since the first 1.2 release - with the MacOSX
> backend line plots of somewhat larger arrays with
> significant "high-frequency" power had extremely
> degraded, e.g. something like
> 
> x = np.linspace(0,10,1.e6)
> y =
> np.cos(x)+0.2*np.sin(x*3.e3)+0.1*np.cos(x*4.e4)*np.random.rand(1.e6)
> plt.plot(x, y)
> 
> would display within less than 2 seconds with 1.1.1, but
> with 1.2.x you literally have to wait minutes,
> and it takes similarly long to zoom in as long as you have a
> substantial part of the line in the window.
> 
> I found in the current HEAD (9e477b3) this has finally been
> fixed - thanks for that as well, whatever
> the problem was, but now in the 1.3 branch the _macosx
> backend has been altogether disabled!
> I verified after removing that RuntimeError from _macosx.m
> that the backend still works and is indeed
> up to its old speed; but if that change stays in, it won't
> be usable from non-framework Python installs
> like the fink ones. 
> Personally, I am aware of the problems with the missing
> window manager control, and occasionally
> am annoyed by hunting for a plot window that has sneaked
> somewhere underneath other windows,
> but with that in mind I still prefer the MacOSX backend to
> any of the others, and I would suggest to
> leave it at a warning rather than an error, so users can
> still decide for themselves if they want to put
> up with the possible troubles.
> 
> Cheers,
>            
>            
>     Derek
> 
> 
> ------------------------------------------------------------------------------
> Precog is a next-generation analytics platform capable of
> advanced
> analytics on semi-structured data. The platform includes
> APIs for building
> apps and a phenomenal toolset for data science. Developers
> can use
> our toolset for easy data analysis & visualization. Get
> a free account!
> http://www2.precog.com/precogplatform/slashdotnewsletter
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 

On 11.04.2013, at 6:38PM, Michael Droettboom <md...@st...> wrote:

> Congrats to everyone on a successful 1.2.1 -- there was a relatively 
> small influx of bug reports following it -- perhaps a sign of improving 
> quality?

Thanks and congratulations to everyone involved as well; I've built 1.2.1 on MacOS X with fink for 
Python2.6-3.2 without any failures in the test suite!
I did run into a problem though that has actually existed since the first 1.2 release - with the MacOSX
backend line plots of somewhat larger arrays with significant "high-frequency" power had extremely
degraded, e.g. something like

x = np.linspace(0,10,1.e6)
y = np.cos(x)+0.2*np.sin(x*3.e3)+0.1*np.cos(x*4.e4)*np.random.rand(1.e6)
plt.plot(x, y)

would display within less than 2 seconds with 1.1.1, but with 1.2.x you literally have to wait minutes,
and it takes similarly long to zoom in as long as you have a substantial part of the line in the window.

I found in the current HEAD (9e477b3) this has finally been fixed - thanks for that as well, whatever
the problem was, but now in the 1.3 branch the _macosx backend has been altogether disabled!
I verified after removing that RuntimeError from _macosx.m that the backend still works and is indeed
up to its old speed; but if that change stays in, it won't be usable from non-framework Python installs
like the fink ones. 
Personally, I am aware of the problems with the missing window manager control, and occasionally
am annoyed by hunting for a plot window that has sneaked somewhere underneath other windows,
but with that in mind I still prefer the MacOSX backend to any of the others, and I would suggest to
leave it at a warning rather than an error, so users can still decide for themselves if they want to put
up with the possible troubles.

Cheers,
							Derek