Re: [matplotlib-devel] Triplot function problems
Hello Ian and John, It's perfect!!! Works very well!!! Now it takes only 5 s to do the contour and triplot of a grid with 45000 nodes and 85000 elements/triangles. Thank you very much for your support!!! Best regards, Alberto === 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.15370) 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
[matplotlib-devel] Error
Hi guys, I just installed matplotlib (0.99.3) and numpy (1.4.1), for python 2.6 (I'm running on Win7). I used the Windows installer for both. I added one line to my previously-working script: import matplotlib.pyplot as plt And I now get the following: import matplotlib.pyplot as plt File C:\Python26\lib\site-packages\matplotlib\__init__.py, line 129, in module from rcsetup import defaultParams, validate_backend, validate_toolbar File C:\Python26\lib\site-packages\matplotlib\rcsetup.py, line 19, in module from matplotlib.colors import is_color_like File C:\Python26\lib\site-packages\matplotlib\colors.py, line 52, in module import numpy as np File C:\Python26\lib\site-packages\numpy\__init__.py, line 132, in module import add_newdocs File C:\Python26\lib\site-packages\numpy\add_newdocs.py, line 9, in module from lib import add_newdoc File C:\Python26\lib\site-packages\numpy\lib\__init__.py, line 4, in module from type_check import * File C:\Python26\lib\site-packages\numpy\lib\type_check.py, line 8, in module import numpy.core.numeric as _nx File C:\Python26\lib\site-packages\numpy\core\__init__.py, line 5, in module import multiarray ImportError: DLL load failed: %1 is not a valid Win32 application. Any idea what's going wrong? Thanks, -Michael -- 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] branching for 1.0
Sorry, this is the first email I've received on the matter. I only subscribed to the list today though. Thanks, -Michael On 6 Jul 2010 14:44, John Hunter jdh2...@gmail.com wrote: On Mon, Jul 5, 2010 at 5:31 PM, John Hunter jdh2...@gmail.com wrote: 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. I'm going top infer by your silence Michael that you may be on vacation so I am going to proceed with making the release branch. Fingers crossed. 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 -- 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] branching for 1.0
On Tue, Jul 6, 2010 at 9:46 AM, Michael Pearce michaelppea...@gmail.com wrote: Sorry, this is the first email I've received on the matter. I only subscribed to the list today though.\ No worries, I was referring to Michael Droettboom :-) -- 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] branching for 1.0
On Tue, Jul 6, 2010 at 8:43 AM, John Hunter jdh2...@gmail.com wrote: On Mon, Jul 5, 2010 at 5:31 PM, John Hunter jdh2...@gmail.com wrote: 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. I'm going top infer by your silence Michael that you may be on vacation so I am going to proceed with making the release branch. Fingers crossed. I think I followed the instructions pretty closely, but merge tracking still appears to be breaking. We had problems with this on the 99 main branch and Michael was at a loss to fix them. The branch is created and you can check out and commit to it, but merge tracking is breaking. The branch does not show up in when you call 'svnmerge.py merge' even after doing svnmerge.py init https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/branches/v1_0_maint OR svnmerge.py init https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/branches/v1_0_maint --force and then committing. I am going to proceed with the release from the branch, but merge tracking maybe FUBAR for a while. We can fall back on svn merge I suppose if MGD can't figure out what is wrong with this. You can get the maintenance branch from: svn co https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/branches/v1_0_maint mpl1 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] Help with blitting bug with subplots and markers
On 07/04/2010 09:32 PM, John Hunter wrote: On Sat, Jul 3, 2010 at 11:53 AM, Ryan Mayrma...@gmail.com wrote: On Sat, Jul 3, 2010 at 1:11 AM, Ryan Mayrma...@gmail.com wrote: Alright, before I go to bed, I found the following line in src/_backend_agg.cpp at line 709 (in draw_markers()) makes all the difference: set_clipbox(gc.cliprect, rendererBase); Commenting out this line fixes my problem. I'm not sure why it's a problem, (maybe a missing restore to previous state somewhere?). I'll look into this tomorrow, but it would probably be a lot easier with someone familiar with the code. Following up again, it seems like the problem is that draw_marker is calling set_clipbox() on the rendererBase instead of theRasterizer, which is done at 7 other places in the code (as opposed to only one other location for rendererBase). Since rendererBase is used for restore_region, this makes sense as to why it would fix my problem. I can confirm making the change fixes my problem and doesn't cause any other issues in my (admittedly brief so far) testing. (If this isn't the proper fix, an alternative is to call rendererBase.reset_clipping(true), but I really think this is working around the issue). Can someone more familiar with the agg backend weigh in here? I'm pretty comfortable with the fix, but don't want to be responsible for breaking pretty much all of matplotlib. Does marker clipping still work with the proposed change? Unfortunately, not. Ryan's suggestion to call rendererBase.reset_clipping(true) upon exit of draw_markers does seem to work both for the blitting and clipping, however. I don't think this is working around the issue -- I think it's probably the correct solution. The clipping state really should probably be reset around every backend call -- but this is the first instance we've seen where the stickiness is a problem, so I think I'll only fix it here (and not reset all the clipping calls to theRasterizer). I've committed this change to 8515. Mike The only thing that is special about marker drawing is we use cached marker rasters to make drawing many of them efficient, but I don't recall anymore whether this required special clipping treatment. 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 -- Michael Droettboom Science Software Branch Space Telescope Science Institute Baltimore, Maryland, USA -- 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] branching for 1.0
On 07/06/2010 10:56 AM, John Hunter wrote: On Tue, Jul 6, 2010 at 8:43 AM, John Hunterjdh2...@gmail.com wrote: On Mon, Jul 5, 2010 at 5:31 PM, John Hunterjdh2...@gmail.com wrote: 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. I'm going top infer by your silence Michael that you may be on vacation so I am going to proceed with making the release branch. Fingers crossed. I think I followed the instructions pretty closely, but merge tracking still appears to be breaking. We had problems with this on the 99 main branch and Michael was at a loss to fix them. The branch is created and you can check out and commit to it, but merge tracking is breaking. The branch does not show up in when you call 'svnmerge.py merge' even after doing svnmerge.py init https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/branches/v1_0_maint OR svnmerge.py init https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/branches/v1_0_maint --force and then committing. Did you run this from a working copy of the trunk? That worked for me. (A merge init always has a from and a to, where the to is implied by the current working copy). I believe (though a little testing) that merging from the branch to the trunk is now working. Mike -- Michael Droettboom Science Software Branch Space Telescope Science Institute Baltimore, Maryland, USA -- 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] Error
From the traceback, it looks like the problem is entirely within importing numpy. Does import numpy also give you an error? If so, you may have more luck asking this question on the Numpy mailing list (not that this question isn't unwelcome here, of course ;) Mike On 07/06/2010 08:27 AM, Michael Pearce wrote: Hi guys, I just installed matplotlib (0.99.3) and numpy (1.4.1), for python 2.6 (I'm running on Win7). I used the Windows installer for both. I added one line to my previously-working script: import matplotlib.pyplot as plt And I now get the following: import matplotlib.pyplot as plt File C:\Python26\lib\site-packages\matplotlib\__init__.py, line 129, in module from rcsetup import defaultParams, validate_backend, validate_toolbar File C:\Python26\lib\site-packages\matplotlib\rcsetup.py, line 19, in module from matplotlib.colors import is_color_like File C:\Python26\lib\site-packages\matplotlib\colors.py, line 52, in module import numpy as np File C:\Python26\lib\site-packages\numpy\__init__.py, line 132, in module import add_newdocs File C:\Python26\lib\site-packages\numpy\add_newdocs.py, line 9, in module from lib import add_newdoc File C:\Python26\lib\site-packages\numpy\lib\__init__.py, line 4, in module from type_check import * File C:\Python26\lib\site-packages\numpy\lib\type_check.py, line 8, in module import numpy.core.numeric as _nx File C:\Python26\lib\site-packages\numpy\core\__init__.py, line 5, in module import multiarray ImportError: DLL load failed: %1 is not a valid Win32 application. Any idea what's going wrong? Thanks, -Michael -- 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 -- Michael Droettboom Science Software Branch Space Telescope Science Institute Baltimore, Maryland, USA -- 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] Error
On 07/06/2010 11:40 AM, Michael Droettboom wrote: (not that this question isn't unwelcome here, of course ;) I mistyped -- I was merely trying to be friendly and say your question is still welcome here. :) Mike Mike On 07/06/2010 08:27 AM, Michael Pearce wrote: Hi guys, I just installed matplotlib (0.99.3) and numpy (1.4.1), for python 2.6 (I'm running on Win7). I used the Windows installer for both. I added one line to my previously-working script: import matplotlib.pyplot as plt And I now get the following: import matplotlib.pyplot as plt File C:\Python26\lib\site-packages\matplotlib\__init__.py, line 129, in module from rcsetup import defaultParams, validate_backend, validate_toolbar File C:\Python26\lib\site-packages\matplotlib\rcsetup.py, line 19, in module from matplotlib.colors import is_color_like File C:\Python26\lib\site-packages\matplotlib\colors.py, line 52, in module import numpy as np File C:\Python26\lib\site-packages\numpy\__init__.py, line 132, in module import add_newdocs File C:\Python26\lib\site-packages\numpy\add_newdocs.py, line 9, in module from lib import add_newdoc File C:\Python26\lib\site-packages\numpy\lib\__init__.py, line 4, in module from type_check import * File C:\Python26\lib\site-packages\numpy\lib\type_check.py, line 8, in module import numpy.core.numeric as _nx File C:\Python26\lib\site-packages\numpy\core\__init__.py, line 5, in module import multiarray ImportError: DLL load failed: %1 is not a valid Win32 application. Any idea what's going wrong? Thanks, -Michael -- 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 -- Michael Droettboom Science Software Branch Space Telescope Science Institute Baltimore, Maryland, USA -- Michael Droettboom Science Software Branch Space Telescope Science Institute Baltimore, Maryland, USA -- 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] branching for 1.0
On Tue, Jul 6, 2010 at 10:34 AM, Michael Droettboom md...@stsci.edu wrote: Did you run this from a working copy of the trunk? That worked for me. (A merge init always has a from and a to, where the to is implied by the current working copy). I believe (though a little testing) that merging from the branch to the trunk is now working. I first ran it from trunk/matplotlib, and then thought maybe you meant trunk trunk, so I deleted the branch, recreated it, and did the svnmerge init from trunk. I'll test after your changes -- if I recall correctly we've been optimistic before only to see the merge tracking disappear. It appears to be working, though, so you clearly sprinkled your magic pixie dust on it. Thanks for taking a look. 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] Adding more image format support...
We've had some requests from internal users here at STScI to make it easier to save JPEG files directly from matplotlib. We currently support JPEG saving from the Gtk* and Wx* backends (because those libraries come with JPEG saving support), but not in the Tk backend that most of our users use. One solution to this may be to add an optional dependency on PIL, and if found save JPEG files (and maybe some of the other esoteric formats PIL supports). The work done a couple of years back to manage the supported file types should make this pretty easy. While adding a hard dependency on PIL is probably not a good idea, are there any objections to making it a soft dependency? Mike -- Michael Droettboom Science Software Branch Space Telescope Science Institute Baltimore, Maryland, USA -- 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] Adding more image format support...
On Tue, Jul 6, 2010 at 2:07 PM, Michael Droettboom md...@stsci.edu wrote: We've had some requests from internal users here at STScI to make it easier to save JPEG files directly from matplotlib. We currently support JPEG saving from the Gtk* and Wx* backends (because those libraries come with JPEG saving support), but not in the Tk backend that most of our users use. One solution to this may be to add an optional dependency on PIL, and if found save JPEG files (and maybe some of the other esoteric formats PIL supports). The work done a couple of years back to manage the supported file types should make this pretty easy. While adding a hard dependency on PIL is probably not a good idea, are there any objections to making it a soft dependency? None here, especially when the alternative is writing our own bindings to the jpeg library. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma -- 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
No problem. I am glad that it is useful. Yes, you can have a figure with a mix of 2D subplots and 3D subplots. I will make sure I include an example of that as well. I will look into updating the rst file, and also the current batch of examples to use the new approach. I am honored you would offer me commit rights. I will contact you off list for more information. About the animations, I do have a prototype of it, and it works even on my EeePC, however Ryan May and I are still working out some issues (particularly with rotating and zooming). Thanks, Ben Root On Mon, Jul 5, 2010 at 6:18 PM, John Hunter jdh2...@gmail.com wrote: On Sat, Jul 3, 2010 at 1:51 AM, Benjamin Root ben.v.r...@gmail.com 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
Re: [matplotlib-devel] Adding more image format support...
On Tue, Jul 6, 2010 at 2:07 PM, Michael Droettboom md...@stsci.edu wrote: We've had some requests from internal users here at STScI to make it easier to save JPEG files directly from matplotlib. We currently support JPEG saving from the Gtk* and Wx* backends (because those libraries come with JPEG saving support), but not in the Tk backend that most of our users use. One solution to this may be to add an optional dependency on PIL, and if found save JPEG files (and maybe some of the other esoteric formats PIL supports). The work done a couple of years back to manage the supported file types should make this pretty easy. While adding a hard dependency on PIL is probably not a good idea, are there any objections to making it a soft dependency? No objections from me -- we already optionally use it in imread. 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] Improvements to boxplots
Looks like my evenings this week (after today) will be open. I was thinking about coding up a potentially major overhaul of the axes.Axes.boxplot. Here's a rough outline of what I was thinking: 1) Improve the bootstrapping of the confidence intervals around the median 2) Add support for masked arrays (i.e., let user specify if masked values should be considered or not -- currently they are always considered, IIRC) 3) Improve the calculation of the percentiles to be consistent with SciPy and R. #1 seems like something that'll be nice. #2 seems pretty essential to me. The third improvement is something for which I would want y'all's blessing before moving ahead. However, I think it's pretty critical. See (25th and 75th percentiles) below: import numpy as np import matplotlib.mlab as mlab import scipy.stats as stats def comparePercentiles(x): mlp = mlab.prctile(x) stp = np.array([]) for p in (0.0, 25.0, 50.0, 75.0, 100.0): stp = np.hstack([stp, stats.scoreatpercentile(x,p)]) outstring = mlab \t scipy - %0.3f \t %0.3f (0th) %0.3f \t %0.3f (25th) %0.3f \t %0.3f (50th) %0.3f \t %0.3f (75th) %0.3f \t %0.3f (100th) % (mlp[0], stp[0], mlp[1], stp[1], mlp[2], stp[2], mlp[3], stp[3], mlp[4], stp[4]) print(outstring) comparePercentiles(x) mlab scipy -- -1.245 -1.245 (0th) -0.950 -0.802 (25th) -0.162 -0.162 (50th) 0.5710.266 (75th) 1.0671.067 (100th) Copying and pasting the exact same data into R I get: quantile(x, probs=c(0.0, 0.25, 0.50, 0.75, 1.0)) 0%25%50%75% 100% -1.2448508 -0.8022337 -0.1617812 0.2661112 1.0666244 Seems like it's clear that something needs to be done. AFAICT, scipy is not listed as a dependency of matplotlib, so it'll probably just be easier to retool mlab.prctile to return values that agree with scipy and R. What do you think? Would this be a welcome contribution? Thanks, -Paul Hobson -- 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] Improvements to boxplots
On 07/06/2010 10:55 AM, phob...@geosyntec.com wrote: Looks like my evenings this week (after today) will be open. I was thinking about coding up a potentially major overhaul of the axes.Axes.boxplot. Here's a rough outline of what I was thinking: 1) Improve the bootstrapping of the confidence intervals around the median 2) Add support for masked arrays (i.e., let user specify if masked values should be considered or not -- currently they are always considered, IIRC) Support for masked arrays should always be implemented such that masked values are skipped--don't make that optional, please. 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] Help with blitting bug with subplots and markers
On Tue, Jul 6, 2010 at 10:19 AM, Michael Droettboom md...@stsci.edu wrote: On 07/04/2010 09:32 PM, John Hunter wrote: On Sat, Jul 3, 2010 at 11:53 AM, Ryan Mayrma...@gmail.com wrote: On Sat, Jul 3, 2010 at 1:11 AM, Ryan Mayrma...@gmail.com wrote: Alright, before I go to bed, I found the following line in src/_backend_agg.cpp at line 709 (in draw_markers()) makes all the difference: set_clipbox(gc.cliprect, rendererBase); Commenting out this line fixes my problem. I'm not sure why it's a problem, (maybe a missing restore to previous state somewhere?). I'll look into this tomorrow, but it would probably be a lot easier with someone familiar with the code. Following up again, it seems like the problem is that draw_marker is calling set_clipbox() on the rendererBase instead of theRasterizer, which is done at 7 other places in the code (as opposed to only one other location for rendererBase). Since rendererBase is used for restore_region, this makes sense as to why it would fix my problem. I can confirm making the change fixes my problem and doesn't cause any other issues in my (admittedly brief so far) testing. (If this isn't the proper fix, an alternative is to call rendererBase.reset_clipping(true), but I really think this is working around the issue). Can someone more familiar with the agg backend weigh in here? I'm pretty comfortable with the fix, but don't want to be responsible for breaking pretty much all of matplotlib. Does marker clipping still work with the proposed change? Unfortunately, not. Ryan's suggestion to call rendererBase.reset_clipping(true) upon exit of draw_markers does seem to work both for the blitting and clipping, however. I don't think this is working around the issue -- I think it's probably the correct solution. The clipping state really should probably be reset around every backend call -- but this is the first instance we've seen where the stickiness is a problem, so I think I'll only fix it here (and not reset all the clipping calls to theRasterizer). I've committed this change to 8515. Mike Did this make it into 1.0.0? I didn't see it in the merges you did earlier? If not, can we get it into the stable branch for the next bugfix release? I'd love to only require the latest release (and not trunk) when I finally put out my animation stuff for wider testing. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma -- 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] HTML5 Matplotlib Backend
On Mon, Jun 21, 2010 at 7:51 AM, william ratcliff william.ratcl...@gmail.com wrote: I just tested it and it's very cool! It works fairly quickly locally. It seems to work for Safari 5 and Chrome beta. Firefox 3.6.3 is a no show. I haven't tried Opera. What I'm really curious about is what is the latency like over the actual internet, or under higher server loads (given the round tripping). For us, I'd have to try to get it to work for firefox (I think as a cross platform browser, it's fairly common, especially on linux systems like Fedora, it's what the user is most likely to have.). Thanks for sharing this! William On Mon, Jun 21, 2010 at 9:19 AM, Simon Ratcliffe sratcli...@gmail.com wrote: Hello, Our HTML5 based matplotlib backend is now available at: http://code.google.com/p/mplh5canvas/ There are some basic installation instructions and included examples to get going. Keep in mind that the weakest link at this stage is browser support. We recommend Chrome for the most hassle free experience. This is very much a beta release and has not seen action outside of our internal testing, so we expect some teething troubles :) Please let us know what works for you, and what doesn't, and we will try and fix things as they come up. This looks very exciting. I don't know how to install chrome on my rhel5 without root access (I didn't find any binary and the source build fails due to some missing dependencies) and I have FF3.6.6, but I'll try to download some development binary of FF, so that it works. Ondrej -- 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] latex problem in example
I am working on converting examples in the mplot3d directory when I discovered that pathpatch3d_demo.py seems to fail while using LaTeX. I am getting an error LaTeX Error: File `type1cm.sty' not found. Is anyone else having this issue or is there something that needs to be setup properly first? Thanks, Ben Root -- 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
