Re: [matplotlib-devel] Triplot function problems
Hello again Alberto, On 4 July Alberto Azevedo wrote: > When I use the triplot function with 100-1000 points it works well. The > problem is that in my work I often use grids with 3-10 > points. With those grids triplot takes a long time to compute (I never > wait for the results, it takes really a long time). > Yes, it does indeed take a long time for large grids. The bottleneck is line 51 in lib/matplotlib/tri/triplot - I use the plot command which creates a separate Line2D object for each edge in the triangulation, and there can be a lot of edges. There is an obvious improvement of replacing this with a single LineCollection object, but it would require some manipulation of the line styles, colours, etc that the plot command does and I don't yet understand it sufficiently. The matlab triplot function takes just a few seconds, with the same > grids). It's bad etiquette to indicate that matlab is faster when addressing people who give up their free time to improve matplotlib, and possibly counter-productive. And when I was using mpl_tri package, I never had this problem > (the triplot function was faster!!!) > Not true, the final line in the now obsolete mpl_tri.triplot was exactly the same plot() command. I'll take a look at improving the performance, but it won't for a few days. Ian -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Triplot function problems
Hello Ian, I'm really sorry for my comment, it was not my intention to offend anyone. You are absolutely right about that, therefore I would like to apologize to all developers, in particular to you, for my comment regarding the matlab comparison. The only thing I can promise is that won't happen again... sorry!!! You said that the obsolete triplot has the same code lines. I don't know what has changed between the two versions, but the fact is that I made many plots when I was using mpl_tri (yes, it take a while, but not so long as with the new version). Best regards, Alberto On 05-07-2010 9:17, Ian Thomas wrote: Hello again Alberto, On 4 July Alberto Azevedo wrote: When I use the triplot function with 100-1000 points it works well. The problem is that in my work I often use grids with 3-10 points. With those grids triplot takes a long time to compute (I never wait for the results, it takes really a long time). Yes, it does indeed take a long time for large grids. The bottleneck is line 51 in lib/matplotlib/tri/triplot - I use the plot command which creates a separate Line2D object for each edge in the triangulation, and there can be a lot of edges. There is an obvious improvement of replacing this with a single LineCollection object, but it would require some manipulation of the line styles, colours, etc that the plot command does and I don't yet understand it sufficiently. The matlab triplot function takes just a few seconds, with the same grids). It's bad etiquette to indicate that matlab is faster when addressing people who give up their free time to improve matplotlib, and possibly counter-productive. And when I was using mpl_tri package, I never had this problem (the triplot function was faster!!!) Not true, the final line in the now obsolete mpl_tri.triplot was exactly the same plot() command. I'll take a look at improving the performance, but it won't for a few days. Ian === E-mail verificado pelo Spyware Doctor Não foram encontrados vírus ou spyware. (Email Guard: 7.0.0.18, Base de dados de vírus/spyware: 6.15350) http://www.pctools.com/?cclick=EmailFooterClean_51 === -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Triplot function problems
On Mon, Jul 5, 2010 at 4:36 AM, Alberto Azevedo wrote: > I'm really sorry for my comment, it was not my intention to offend anyone. > You are absolutely right about that, therefore I would like to apologize to > all developers, in particular to you, for my comment regarding the matlab > comparison. > The only thing I can promise is that won't happen again... sorry!!! Speaking for myself , I did not find your comment offensive. It is true we are an all-volunteer organization and do not strive to duplicate matlab, but I took your comment to mean that the plotting could be done efficiently as evidenced by matlab, so there was no algorithmic reason it should be as slow as it is. Those kinds of comments, phrased gently and constructively, are generally welcome. The tri functionality is quite new, not yet in any released versions of mpl but that is soon to change, and often users have to pound on new functionality for a while to shake out inefficiencies As Ian noted, anywhere we use a long list of Line2D objects (or calls to plot in a loop) is prone to be very slow, and we should be able to get substantial performance improvements using a collection. Cheers, JDH -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Triplot function problems
On Mon, Jul 5, 2010 at 3:17 AM, Ian Thomas wrote: > Yes, it does indeed take a long time for large grids. The bottleneck is line > 51 in lib/matplotlib/tri/triplot - I use the plot command which creates a > separate Line2D object for each edge in the triangulation, and there can be > a lot of edges. There is an obvious improvement of replacing this with a > single LineCollection object, but it would require some manipulation of the > line styles, colours, etc that the plot command does and I don't yet > understand it sufficiently. This could be made much faster using a compound Path for the edges and a single call to "plot" for the markers on the flattened array of vertices. You would retain the generality of all the mpl markers in this case, since you would be using "plot" for the verticies, but might lose some of the generality of the line styles since we don't have a class "LinePath" like we do in matplotlib.patches.PathPatch (eg see http://matplotlib.sourceforge.net/examples/api/compound_path.html). It would be nice to see an analogue or PathPatch matplotlib.lines.LinePath that exposes the relevant bits of the Line2D interface (set_linestyle) etc, but you can get most of this by setting facecolor='None' in the PathPatch. In practice, you almost always want a solid line for the edges I suspect. In a nutshell, you could still support the plot format string but manually pass it to Axes._process_plot_format. Use the returned results to set the properties on a single call to plot for the flattened array of vertex markers, and a single compound PathPatch with no facecolor for the edges (or you could support the facecolor if you want). Since PathPatch already supports linestyle, edgecolor and linewidth, it should work. And Paths support masks, so you should be able to integrate the masking but I am not sure about this part since I haven't delved deeply enough into the tri code to see how masking is applied. JDH -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] show() is now more uniform across backends
http://www.mail-archive.com/matplotlib-devel@lists.sourceforge.net/msg06691.html Looking back through mail, I noticed the above thread that was still hanging with respect to 1.0. A few minutes ago, in 8494, I went ahead and committed a change that makes show block in tkagg and fltkagg, just as it does in all the other interactive backends. As usual, other developers are *welcome* *to* *revert* this change; but I think it is an important one to get into 1.0 if possible, since it helps smooth out an inconsistency that keeps surprising users. Again, I hope someone can test 8494 right now. It would be especially useful if someone with an older OS version could test it. I run ubuntu 10.04, so there is always the danger that something that works fine for me might not work for someone with an old RHEL or Windows XP or OSX 10.4. The change affects *only* show() on tkagg and fltkagg. I don't expect it will magically make all backends work exactly the same in all possible environments (ipython -pylab, idle, etc.), but as far as I can tell it is a step in the right direction; I don't expect it to make anything substantially worse. In retrospect, I think I was too cautious; I should have simply made the change in svn 3 weeks ago. The only way to get much testing of something like this is to put it in by default--not as an option requiring deliberate testing--and see if anyone trips over it. Eric -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Typo in mplconf
After some more digging, I think I finally found the source of my issues. I
have noticed that there are inconsistencies between the keys and sections
listed in the default matplotlib.conf file and in the class MPLConfig().
While in most cases, these inconsistencies are innocuous and do not cause
errors, I think there have been a few inadvertent mistakes.
So, I modified one of the programs to produce a list of all the
inconstancies that exist, and I will let you guys figure out what needs to
be fixed, or what is intentional.
For example, the first item in thee file states that the MPLConfig class do
not have the keys "numerix" and "maskedarray", but the default configuration
file does. In addition, the MPLConfig class has the key datapath, but that
is not given in the default conf file. (I do recognize that this should
probably be expected in this case, I am merely explaining how to interpret
the attached file).
The next paragraph states that MPLConfig class defines a section "path", but
it is not found in the default configuration file.
The other lines that I find interesting:
15 ('preview' is given in the conf file, but not in the class)
31-32 ('embed_chars' is in the default file, but the config class has
'embed_char_paths')
35-36 (many keys between the class and the file are similar, but not the
same)
The other paragraphs might be interesting, but I hardly know enough to make
such determinations.
Ben Root
On Sun, Jul 4, 2010 at 9:47 PM, Benjamin Root wrote:
>
>
> On Sun, Jul 4, 2010 at 9:43 PM, Darren Dale wrote:
>
>> On Sun, Jul 4, 2010 at 9:24 PM, John Hunter wrote:
>> > On Sun, Jul 4, 2010 at 4:46 PM, Benjamin Root wrote:
>> >> Hello,
>> >>
>> >> I came across a typo in mplconfig.py that results in an error when
>> >> processing the matplotlib configurations. Attached is a patch.
>> >
>> > I can apply this patch because it is a simple fix, but the larger
>> > question is whether we want to distribute/support the traited config
>> > at all. It seems like this development branch is mostly abandoned.
>> > Any comments Darren, or others?
>> >
>> > But in any case as long as we *do* currently have it it is good to fix
>> > these bugs, so thanks for the patch.
>>
>> The traited config stuff was never supported, and has to be turned on
>> by setting a global in the source code. So I don't think it makes
>> sense to distribute it. I'm too busy these days to try to support this
>> feature and make it the default, plus there were issues with
>> additional overhead due to pkg_resources, traits, and configobj. I
>> wouldn't be offended if the code was removed from the trunk. (sniffs)
>>
>> Darren
>>
>
> Do you guys still want a bug report for the tconfig issue, just in case it
> might be related to Traits in general (I have no clue where the issue is
> happening)?
>
> Ben
>
./matplotlib/lib/matplotlib/mpl-data/matplotlib.conf
Inconsistencies found for section: MPLConfig
These keys are missing from the config class: ['maskedarray', 'numerix']
And the config class has these: ['datapath']
Inconsistencies found within section: MPLConfig
These subsections are missing from the config class : []
And the config class has these : ['path']
Inconsistencies found for section: text
These keys are missing from the config class: []
And the config class has these: ['hinting']
Inconsistencies found for section: latex
These keys are missing from the config class: ['preview']
And the config class has these: []
Inconsistencies found for section: mathtext
These keys are missing from the config class: []
And the config class has these: ['default']
Inconsistencies found for section: path
These keys are missing from the config class: []
And the config class has these: ['snap', 'simplify', 'simplify_threshold']
Inconsistencies found for section: backend
These keys are missing from the config class: []
And the config class has these: ['fallback']
Inconsistencies found for section: svg
These keys are missing from the config class: ['embed_chars']
And the config class has these: ['embed_char_paths']
Inconsistencies found for section: legend
These keys are missing from the config class: ['handlelength', 'labelspacing',
'columnspacing', 'handletextpad', 'borderaxespad', 'borderpad']
And the config class has these: ['handletextsep', 'axespad', 'pad', 'labelsep',
'handlelen']
--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Typo in mplconf
On 07/05/2010 10:22 AM, Benjamin Root wrote:
> After some more digging, I think I finally found the source of my
> issues. I have noticed that there are inconsistencies between the keys
> and sections listed in the default matplotlib.conf file and in the class
> MPLConfig(). While in most cases, these inconsistencies are innocuous
> and do not cause errors, I think there have been a few inadvertent mistakes.
Ben,
With Darren's permission I went ahead and deleted matplotlib.config from
svn (r8495), so it will not appear in the next release unless someone
resurrects it. It can always be pulled out of the svn history and
updated, if that turns out to be the thing to do. For now, though, I
think that it is better to simplify the mpl tree when possible. We have
enough work to do to maintain and improve the parts of mpl that are
being used.
Eric
>
> So, I modified one of the programs to produce a list of all the
> inconstancies that exist, and I will let you guys figure out what needs
> to be fixed, or what is intentional.
>
> For example, the first item in thee file states that the MPLConfig class
> do not have the keys "numerix" and "maskedarray", but the default
> configuration file does. In addition, the MPLConfig class has the key
> datapath, but that is not given in the default conf file. (I do
> recognize that this should probably be expected in this case, I am
> merely explaining how to interpret the attached file).
>
> The next paragraph states that MPLConfig class defines a section "path",
> but it is not found in the default configuration file.
>
> The other lines that I find interesting:
> 15 ('preview' is given in the conf file, but not in the class)
> 31-32 ('embed_chars' is in the default file, but the config class
> has 'embed_char_paths')
> 35-36 (many keys between the class and the file are similar, but not
> the same)
>
> The other paragraphs might be interesting, but I hardly know enough to
> make such determinations.
>
> Ben Root
>
>
> On Sun, Jul 4, 2010 at 9:47 PM, Benjamin Root > wrote:
>
>
>
> On Sun, Jul 4, 2010 at 9:43 PM, Darren Dale > wrote:
>
> On Sun, Jul 4, 2010 at 9:24 PM, John Hunter > wrote:
> > On Sun, Jul 4, 2010 at 4:46 PM, Benjamin Root
> mailto:ben.r...@ou.edu>> wrote:
> >> Hello,
> >>
> >> I came across a typo in mplconfig.py that results in an
> error when
> >> processing the matplotlib configurations. Attached is a patch.
> >
> > I can apply this patch because it is a simple fix, but the larger
> > question is whether we want to distribute/support the traited
> config
> > at all. It seems like this development branch is mostly
> abandoned.
> > Any comments Darren, or others?
> >
> > But in any case as long as we *do* currently have it it is
> good to fix
> > these bugs, so thanks for the patch.
>
> The traited config stuff was never supported, and has to be
> turned on
> by setting a global in the source code. So I don't think it makes
> sense to distribute it. I'm too busy these days to try to
> support this
> feature and make it the default, plus there were issues with
> additional overhead due to pkg_resources, traits, and configobj. I
> wouldn't be offended if the code was removed from the trunk.
> (sniffs)
>
> Darren
>
>
> Do you guys still want a bug report for the tconfig issue, just in
> case it might be related to Traits in general (I have no clue where
> the issue is happening)?
>
> Ben
>
>
>
>
> --
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
>
>
>
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Typo in mplconf
On Mon, Jul 5, 2010 at 3:38 PM, Eric Firing wrote:
> On 07/05/2010 10:22 AM, Benjamin Root wrote:
> > After some more digging, I think I finally found the source of my
> > issues. I have noticed that there are inconsistencies between the keys
> > and sections listed in the default matplotlib.conf file and in the class
> > MPLConfig(). While in most cases, these inconsistencies are innocuous
> > and do not cause errors, I think there have been a few inadvertent
> mistakes.
>
> Ben,
>
> With Darren's permission I went ahead and deleted matplotlib.config from
> svn (r8495), so it will not appear in the next release unless someone
> resurrects it. It can always be pulled out of the svn history and
> updated, if that turns out to be the thing to do. For now, though, I
> think that it is better to simplify the mpl tree when possible. We have
> enough work to do to maintain and improve the parts of mpl that are
> being used.
>
> Eric
>
>
Eric,
No problem, I just noticed that the config directory was removed. And I
just discovered that when svn deletes a directory full of .py and pyc files,
the .pyc files get left behind and are still accessed by programs like pydoc
that walks the directories searching for packages to load.
Anyway, I am more than happy to help prune down the trunk. Extra stuff that
isn't being used just add noise and confusion. Especially to a depth-first
debugger like myself...
Ben Root
>
> > So, I modified one of the programs to produce a list of all the
> > inconstancies that exist, and I will let you guys figure out what needs
> > to be fixed, or what is intentional.
> >
> > For example, the first item in thee file states that the MPLConfig class
> > do not have the keys "numerix" and "maskedarray", but the default
> > configuration file does. In addition, the MPLConfig class has the key
> > datapath, but that is not given in the default conf file. (I do
> > recognize that this should probably be expected in this case, I am
> > merely explaining how to interpret the attached file).
> >
> > The next paragraph states that MPLConfig class defines a section "path",
> > but it is not found in the default configuration file.
> >
> > The other lines that I find interesting:
> > 15 ('preview' is given in the conf file, but not in the class)
> > 31-32 ('embed_chars' is in the default file, but the config class
> > has 'embed_char_paths')
> > 35-36 (many keys between the class and the file are similar, but not
> > the same)
> >
> > The other paragraphs might be interesting, but I hardly know enough to
> > make such determinations.
> >
> > Ben Root
> >
> >
> > On Sun, Jul 4, 2010 at 9:47 PM, Benjamin Root > > wrote:
> >
> >
> >
> > On Sun, Jul 4, 2010 at 9:43 PM, Darren Dale > > wrote:
> >
> > On Sun, Jul 4, 2010 at 9:24 PM, John Hunter > > wrote:
> > > On Sun, Jul 4, 2010 at 4:46 PM, Benjamin Root
> > mailto:ben.r...@ou.edu>> wrote:
> > >> Hello,
> > >>
> > >> I came across a typo in mplconfig.py that results in an
> > error when
> > >> processing the matplotlib configurations. Attached is a
> patch.
> > >
> > > I can apply this patch because it is a simple fix, but the
> larger
> > > question is whether we want to distribute/support the traited
> > config
> > > at all. It seems like this development branch is mostly
> > abandoned.
> > > Any comments Darren, or others?
> > >
> > > But in any case as long as we *do* currently have it it is
> > good to fix
> > > these bugs, so thanks for the patch.
> >
> > The traited config stuff was never supported, and has to be
> > turned on
> > by setting a global in the source code. So I don't think it makes
> > sense to distribute it. I'm too busy these days to try to
> > support this
> > feature and make it the default, plus there were issues with
> > additional overhead due to pkg_resources, traits, and configobj.
> I
> > wouldn't be offended if the code was removed from the trunk.
> > (sniffs)
> >
> > Darren
> >
> >
> > Do you guys still want a bug report for the tconfig issue, just in
> > case it might be related to Traits in general (I have no clue where
> > the issue is happening)?
> >
> > Ben
> >
> >
> >
> >
> >
> --
> > This SF.net email is sponsored by Sprint
> > What will you do first with EVO, the first 4G phone?
> > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> >
> >
> >
> > ___
> > Matplotlib-devel mailing list
> > Matplotlib-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
>
> -
[matplotlib-devel] branching for 1.0
Although there are many active issues that are undergoing constant work, none of these seem release critical and we can continue to improve them on the branch and trunk as need be. Eric, who has been doing the lion's share of the work managing, fixing and closing bugs, feels like we are ready to go and so do I. So Michael, if you are available, will you branch the trunk into a 1.0 maintenance branch, and once the branch is made I will do a final round of testing, cut the tarball, and ask Christoph and Russell to build the binaries. If experience is any guide, after a major *.0 release we will need to cut a bugfix release in the upcoming week or two anyhow, so hopefully we can get as many active issues settled and released by then. If you're not available Michael, let me know or I will infer by your silence and try and make the branch myself from your instructions in the developers guide. Thanks, JDH -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] subplotting 3d figures
Just re-pinging to see if there is any interest in this patch. Ben Root On Sat, Jul 3, 2010 at 1:51 AM, Benjamin Root wrote: > Hello all, > > I have always been a bit troubled with how Axes3D object is a bit of a > 2nd-class citizen in matplotlib. In particular, it is very common to create > a new axes using .add_subplot() or .gca(), but you can't do that with > Axes3D. You also can't create subplots of 3d figures, you have to create > multiple figures with single 3d plots in them. > > My examination off the code have not revealed anything that prevents this > from happening. Currently, the gca() and add_subplot() functions accept a > kwarg of 'projection' which allows one to specify the name of a registered > axes object. Currently axes.Axes, polar and a few others are registered, > with axes.Axes being default. > > I have found that 3 lines of code in the axes3d module to have it add the > Axes3D class to the registry. Using a name of '3d', one can specify the > projection to gain a Axes3d object. Note, you will still have to import the > Axes3D object as usual. Attached is a patch for axes3d.py and a file that > could be added to mpl_examples/. Give it a shot and let me know how it > works for you! > > Enjoy! > Ben Root > > P.S. - Can you just imagine subplots of animated 3d plots? wink... wink... > -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] subplotting 3d figures
On Sat, Jul 3, 2010 at 1:51 AM, Benjamin Root wrote: > Hello all, > > I have always been a bit troubled with how Axes3D object is a bit of a > 2nd-class citizen in matplotlib. In particular, it is very common to create > a new axes using .add_subplot() or .gca(), but you can't do that with > Axes3D. You also can't create subplots of 3d figures, you have to create > multiple figures with single 3d plots in them. > > My examination off the code have not revealed anything that prevents this > from happening. Currently, the gca() and add_subplot() functions accept a > kwarg of 'projection' which allows one to specify the name of a registered > axes object. Currently axes.Axes, polar and a few others are registered, > with axes.Axes being default. > > I have found that 3 lines of code in the axes3d module to have it add the > Axes3D class to the registry. Using a name of '3d', one can specify the > projection to gain a Axes3d object. Note, you will still have to import the > Axes3D object as usual. Attached is a patch for axes3d.py and a file that > could be added to mpl_examples/. Give it a shot and let me know how it > works for you! > > Enjoy! > Ben Root Definitely interested. Thanks for the re-ping. Reinier is busy of late so hasn't been able to get to the 3D stuff. Damned Germans and their endless vacations -- actually my wife is German currently on an endless vacation so shouldn't complain :-) I am not a 3D user currently and was not even aware of the "one axes" limitation you describe. So would this also prevent mixing 2D and 3D in the same figure (in the trunk before your patch)? This looks like a major and unobtrusive improvement. I tested it and it looks good. Committed to 8497. Perhaps you can update doc/mpl_toolkits/mplot3d/tutorial.rst showing how to use the projection kwarg to mix 2D w/ 3D or place multiple 3D plots in one figure. If you'd like svn commit rights, send me your sf id. > P.S. - Can you just imagine subplots of animated 3d plots? wink... wink... Damn, better get a new computer. I am doing my development currently on a linux install running on a laptop under Sun VirtualBox. Even typing an email can be painfully slow. Multiple animated mpl subplots would definitely bring this box to it's knees. Well, technically, it's already on its knees. JDH -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
