Re: [matplotlib-devel] Planning for 1.3.0
On 11.04.2013, at 6:38PM, Michael Droettboom 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Planning for 1.3.0
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 wrote: > From: Derek Homeier > Subject: Re: [matplotlib-devel] Planning for 1.3.0 > To: "[email protected] list" > > Date: Friday, April 12, 2013, 5:16 PM > On 11.04.2013, at 6:38PM, Michael > Droettboom > 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 > [email protected] > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > -- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] interesting article about visualization
http://blogs.hbr.org/cs/2013/04/the_science_of_what_we_do_and_dont_know_about_data_visualization.html -- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Timers independent of canvases
Dear all, The animation code in matplotlib relies on timers to update the animated figures. Currently a new timer is created by calling new_timer on a canvas, as in >>> f = pylab.figure() >>> timer = f.canvas.new_timer() This seems a bit of a wrinkle. For example, you may want to associate a timer with multiple figures, or with no figure at all; also you may want to continue using a timer after a particular figure is closed. I would therefore propose to make timers independent of canvases. Something like this: >>> from matplotlib import events >>> timer = events.Timer() This has the additional advantage of making the different backends more similar to each other; in the current implementation some backends rely on the canvas when making a timer, while others ignore it. I have made a branch on github that does exactly this; see https://github.com/mdehoon/matplotlib/tree/Timer I have verified that the animation examples still work correctly with all backends. Any comments/suggestions/criticisms? If this seems a good idea, I can make a pull request. Best, -Michiel. -- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
