matplotlib-devel Mailing List for matplotlib

Michael Droettboom wrote:
> I've tracked it down to this revision 7395
> 
> http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/branches/v0_99_maint/lib/matplotlib/colors.py?r1=7318&r2=7395&pathrev=7395 
> 
That was John's. I knew there was a reason why I had written it the way 
it was before his change, but I didn't remember what that reason was, 
and didn't spend any time thinking about it.
> 
> was was in response to bug *2832575*
> 
> http://sourceforge.net/tracker/?func=detail&aid=2832575&group_id=80706&atid=560720 
> 
> 
> I think this is reaching my limit of understanding of the color mapping 
> code, so I'm hoping someone else has a solution that will fix one bug 
> without creating another ;)
Yes, this will require some thought. It is just another aspect of the 
alpha mess in mpl in general.
I think there may be at least a crude fix for both the old bug and the 
new one. I will look at it later.
Eric
> 
> Cheers,
> Mike
> 
> 
> ------------------------------------------------------------------------
> 
> 
> ------------------------------------------------------------------------
> 
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with 
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On Fri, Aug 7, 2009 at 11:54 AM, Andrew Straw<str...@as...> wrote:
>> But would this also make the spine have the larger limits? Basically,
>> I want know if the spines can be used to create Tufte-style
>> range-frames. Am I correct in thinking that these spines provide that?
> Although I don't have a precise definition of "Tufte-style range
> frame"to go by, I think my intention was to do exactly what you're after.
One thing you want with range frames is to have the length of the
spine equal the span of your dataset. Can we currently or with not
too much effort define the line segment of the spine to be in data
coords? Then we could make the axes as wide as we want with the ylim
to maintain the clipping region, but the spine would cover just the
span of the data (or whatever the user specified) rather than always
being ymin...ymax if it is defined as 0..1 in axes coords.
JDH

On Fri, Aug 7, 2009 at 2:42 PM, Ryan Wagner<rw...@vn...> wrote:
> Works for me :)
Ditto -- thanks for the quick fix.
JDH

Works for me :)

Should be fixed in SVN now.
Mike
John Hunter wrote:
> On Fri, Aug 7, 2009 at 2:19 PM, Ryan Wagner<rw...@vn...> wrote:
> 
>> Mike, do you see this on your side?
>>
>> ryan@ubuntu-desktop:~/matplotlib/examples/mplot3d$ python surface3d_demo.py
>> *** glibc detected *** python: free(): invalid pointer: 0xbffb3d10 ***
>> 
>
> I'm seeing a core dump on this one (clean build and install of HEAD).
>
> johnh@:svn> cd ~/mpl/examples/mplot3d/
> johnh@:mplot3d> python surface3d_demo.py
> Segmentation Fault (core dumped)
> johnh@:mplot3d> uname -a
> SunOS userver210 5.10 Generic_138889-06 i86pc i386 i86pc
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

I think I almost have a solution. Just running backend_driver.py now.
Mike
John Hunter wrote:
> On Fri, Aug 7, 2009 at 2:19 PM, Ryan Wagner<rw...@vn...> wrote:
> 
>> Mike, do you see this on your side?
>>
>> ryan@ubuntu-desktop:~/matplotlib/examples/mplot3d$ python surface3d_demo.py
>> *** glibc detected *** python: free(): invalid pointer: 0xbffb3d10 ***
>> 
>
> I'm seeing a core dump on this one (clean build and install of HEAD).
>
> johnh@:svn> cd ~/mpl/examples/mplot3d/
> johnh@:mplot3d> python surface3d_demo.py
> Segmentation Fault (core dumped)
> johnh@:mplot3d> uname -a
> SunOS userver210 5.10 Generic_138889-06 i86pc i386 i86pc
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Fri, Aug 7, 2009 at 2:19 PM, Ryan Wagner<rw...@vn...> wrote:
> Mike, do you see this on your side?
>
> ryan@ubuntu-desktop:~/matplotlib/examples/mplot3d$ python surface3d_demo.py
> *** glibc detected *** python: free(): invalid pointer: 0xbffb3d10 ***
I'm seeing a core dump on this one (clean build and install of HEAD).
johnh@:svn> cd ~/mpl/examples/mplot3d/
johnh@:mplot3d> python surface3d_demo.py
Segmentation Fault (core dumped)
johnh@:mplot3d> uname -a
SunOS userver210 5.10 Generic_138889-06 i86pc i386 i86pc

Mike, do you see this on your side?
ryan@ubuntu-desktop:~/matplotlib/examples/mplot3d$ python surface3d_demo.py 
*** glibc detected *** python: free(): invalid pointer: 0xbffb3d10 ***
-----Original Message-----
From: Michael Droettboom [mailto:md...@st...] 
Sent: Friday, August 07, 2009 1:00 PM
To: John Hunter
Cc: Reinier Heeres; Ryan Wagner; mat...@li...
Subject: Re: [matplotlib-devel] Adding Shades Keyword to 3D routines.
John Hunter wrote:
>
> BTW, it looks like the edges of the polys are aliased in the "masked"
> side of the figure. Have you noticed this?
> 
Yeah -- the right hand side is still using the old code path, which is 
aliased by default.
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Wow, no kidding John, what a difference! Great work Mike!
-----Original Message-----
From: John Hunter [mailto:jd...@gm...] 
Sent: Friday, August 07, 2009 12:54 PM
To: Michael Droettboom
Cc: Reinier Heeres; Ryan Wagner; mat...@li...
Subject: Re: [matplotlib-devel] Adding Shades Keyword to 3D routines.
On Fri, Aug 7, 2009 at 1:39 PM, Michael Droettboom<md...@st...> wrote:
> I'm not sure if Gouraud triangles (as supported by Agg, PDF and PS) are
> really sufficient for drawing interpolated quad meshes, because of the
> effect described here:
>
> http://books.google.com/books?id=19SpFYj82owC&lpg=PA280&ots=r3gnxKn9As&dq=shading%20quadrilaterals%20with%20gouraud%20triangles&pg=PA281#v=onepage&q=&f=false
>
> Running quadmesh_demo.py, you can see some sharp edges between triangles in
> the same quad, but it's not too bad in all places. If anyone has any ideas
> about how to ameliorate that effect, feel free to have a crack at it. I
> just wanted to get a proof-of-concept starting point in before heading on
> vacation for a few days.
Wow -- hat tip to you! With productivity like this, how can we afford
to lose you for a few days to vacation :-)
I had to run the example with mpl99 to appreciate the changes, since
you decreased the n from 56 to 12 to show off the effects of the
interpolation, and the interpolation with n=12 is about as visually
good as the grid w/o with n=56. Very nice.
I don't have time to dig into the code now since I have some pressing
work stuff, but I look forward to doing a read-through over the
weekend. Enjoy your vacation, but don't forget your computer graphics
texts and laptop -- I think lighting, shadows and several shaders
should get you through a few days on the beach <wink>
BTW, it looks like the edges of the polys are aliased in the "masked"
side of the figure. Have you noticed this?
JDH

John Hunter wrote:
>
> BTW, it looks like the edges of the polys are aliased in the "masked"
> side of the figure. Have you noticed this?
> 
Yeah -- the right hand side is still using the old code path, which is 
aliased by default.
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Fri, Aug 7, 2009 at 1:39 PM, Michael Droettboom<md...@st...> wrote:
> I'm not sure if Gouraud triangles (as supported by Agg, PDF and PS) are
> really sufficient for drawing interpolated quad meshes, because of the
> effect described here:
>
> http://books.google.com/books?id=19SpFYj82owC&lpg=PA280&ots=r3gnxKn9As&dq=shading%20quadrilaterals%20with%20gouraud%20triangles&pg=PA281#v=onepage&q=&f=false
>
> Running quadmesh_demo.py, you can see some sharp edges between triangles in
> the same quad, but it's not too bad in all places. If anyone has any ideas
> about how to ameliorate that effect, feel free to have a crack at it. I
> just wanted to get a proof-of-concept starting point in before heading on
> vacation for a few days.
Wow -- hat tip to you! With productivity like this, how can we afford
to lose you for a few days to vacation :-)
I had to run the example with mpl99 to appreciate the changes, since
you decreased the n from 56 to 12 to show off the effects of the
interpolation, and the interpolation with n=12 is about as visually
good as the grid w/o with n=56. Very nice.
I don't have time to dig into the code now since I have some pressing
work stuff, but I look forward to doing a read-through over the
weekend. Enjoy your vacation, but don't forget your computer graphics
texts and laptop -- I think lighting, shadows and several shaders
should get you through a few days on the beach <wink>
BTW, it looks like the edges of the polys are aliased in the "masked"
side of the figure. Have you noticed this?
JDH

I have experimental support for Gouraud-shaded pcolormeshes with the Agg 
backend only in SVN trunk. The backend interface will likely change to 
better support PDF, where doing multiple triangles at a time is much 
more efficient. This is just the easiest and far from optimal way to do it.
I'm not sure if Gouraud triangles (as supported by Agg, PDF and PS) are 
really sufficient for drawing interpolated quad meshes, because of the 
effect described here:
http://books.google.com/books?id=19SpFYj82owC&lpg=PA280&ots=r3gnxKn9As&dq=shading%20quadrilaterals%20with%20gouraud%20triangles&pg=PA281#v=onepage&q=&f=false
Running quadmesh_demo.py, you can see some sharp edges between triangles 
in the same quad, but it's not too bad in all places. If anyone has any 
ideas about how to ameliorate that effect, feel free to have a crack at 
it. I just wanted to get a proof-of-concept starting point in before 
heading on vacation for a few days.
Cheers,
Mike
Reinier Heeres wrote:
> Hi,
>
> This looks great! I'd be happy to try and work on this for mplot3d as well.
>
> Ryan: as for your patch, I'll look at it over the weekend or next week
> and see if I can apply it to trunk.
>
> Regards,
> Reinier
>
> On Fri, Aug 7, 2009 at 3:02 PM, Michael Droettboom<md...@st...> wrote:
> 
>> Nevermind -- this is in Agg 2.4 as well. Don't know why I missed it
>> yesterday. I'll have a look into this to see how well we can integrate it.
>>
>> Cheers,
>> Mike
>>
>> Michael Droettboom wrote:
>> 
>>> Ah -- I didn't look at Agg 2.5 at all because of the licensing issues.
>>> Isn't this a no-go for us because it's GPL'd?
>>>
>>> Cheers,
>>> Mike
>>>
>>> John Hunter wrote:
>>>
>>> 
>>>> On Thu, Aug 6, 2009 at 1:53 PM, Michael Droettboom<md...@st...> wrote:
>>>>
>>>>
>>>>
>>>> 
>>>>> Even with this, the gradient infrastructure in Agg assumes a one-dimensional
>>>>> map, and here we need to at least interpolate between the three points of a
>>>>> triangle. It's not impossible, as it's easy enough to make a custom shader,
>>>>> it's just that the gradient code won't help us.
>>>>>
>>>>>
>>>>> 
>>>> I checked in with the antigrain mailing list, as was pointed to
>>>> examples/gouraud.cpp. This looks like what we want, no?
>>>>
>>>> wget http://www.antigrain.com/agg-2.5.tar.gz
>>>> tar xvfz agg-2.5.tar.gz
>>>> cd agg-2.5
>>>> make
>>>> cd examples/X11/
>>>> make gouraud
>>>> ./gouraud
>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>>
>>>> 
>>> 
>> --
>> Michael Droettboom
>> Science Software Branch
>> Operations and Engineering Division
>> Space Telescope Science Institute
>> Operated by AURA for NASA
>> 
>
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

I've tracked it down to this revision 7395
http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/branches/v0_99_maint/lib/matplotlib/colors.py?r1=7318&r2=7395&pathrev=7395
was was in response to bug *2832575*
http://sourceforge.net/tracker/?func=detail&aid=2832575&group_id=80706&atid=560720
I think this is reaching my limit of understanding of the color mapping 
code, so I'm hoping someone else has a solution that will fix one bug 
without creating another ;)
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

John Hunter wrote:
> On Thu, Aug 6, 2009 at 11:31 PM, Ryan Wagner<rw...@vn...> wrote:
>>> Does your workaround work for all supported backends, and with alpha
>>> less than 1? If so, what is it?
>> I believe it will... it is to set the edgecolors (RGBA) of the polygons to that of the facecolors. I will certainly test it on all backends and with several test cases before submitting anything, but it looks promising so far!
> 
> I agree with Eric that lw=0 should mean draw no line at all. In
> postscript, linewidth=0 means "draw the thinnest line you can" but
> early on we overrode this behavior to make the postscript backend
> consistent with other mpl backends, so that linewidth=0 means draw no
> line at all. I think 3D should be consistent with this. But setting
> the edgecolors=facecolors should be fine too -- either of these or
> both can be tested to see what gives the best behavior at the edges.
> 
> JDH
edgecolors=facecolors may cause artifacts with alpha < 1; at least that 
was the experience when we last experimented with similar problems in 
filled contours.
Eric

Brian Granger wrote:
> 
>
> I think this happens in all mpl graphs, you just don't see it. The
> axis limits are set to -2..2, and the sine is draw from -2..2. The
> linewidth extends beyond 2, so it is clipped by the axes clipping to
> the bounding rectangle. Normally you don't see this, because visually
> it is under the surrounding axes black edge. 
>
>
> Yes, I saw that it looks like it happens under the axes clipping.
>
> 
>
> You can either set the
> ylimits wider:
>
> ax.set_ylim(-2.1, 2.1)
>
>
> But would this also make the spine have the larger limits? Basically, 
> I want know if the spines can be used to create Tufte-style 
> range-frames. Am I correct in thinking that these spines provide that?
Although I don't have a precise definition of "Tufte-style range 
frame"to go by, I think my intention was to do exactly what you're after.
I don't know how hard it would be to automatically increase the clipping 
box size by the size (line width or marker size, including edge width) 
of any artists on the border -- I imagine it may require querying 
backends in a way they don't currently support. I'll talk about this 
with John at SciPy 09.
> Or is there another way to get a range-frame?
> 
>
> or turn clipping off
>
> ax.plot(x,y, clip_on=False)
>
>
> This looks hopeful and I will give it a shot.
That's what I've been doing.

Hi,
This looks great! I'd be happy to try and work on this for mplot3d as well.
Ryan: as for your patch, I'll look at it over the weekend or next week
and see if I can apply it to trunk.
Regards,
Reinier
On Fri, Aug 7, 2009 at 3:02 PM, Michael Droettboom<md...@st...> wrote:
> Nevermind -- this is in Agg 2.4 as well. Don't know why I missed it
> yesterday. I'll have a look into this to see how well we can integrate it.
>
> Cheers,
> Mike
>
> Michael Droettboom wrote:
>> Ah -- I didn't look at Agg 2.5 at all because of the licensing issues.
>> Isn't this a no-go for us because it's GPL'd?
>>
>> Cheers,
>> Mike
>>
>> John Hunter wrote:
>>
>>> On Thu, Aug 6, 2009 at 1:53 PM, Michael Droettboom<md...@st...> wrote:
>>>
>>>
>>>
>>>> Even with this, the gradient infrastructure in Agg assumes a one-dimensional
>>>> map, and here we need to at least interpolate between the three points of a
>>>> triangle. It's not impossible, as it's easy enough to make a custom shader,
>>>> it's just that the gradient code won't help us.
>>>>
>>>>
>>> I checked in with the antigrain mailing list, as was pointed to
>>> examples/gouraud.cpp. This looks like what we want, no?
>>>
>>> wget http://www.antigrain.com/agg-2.5.tar.gz
>>> tar xvfz agg-2.5.tar.gz
>>> cd agg-2.5
>>> make
>>> cd examples/X11/
>>> make gouraud
>>> ./gouraud
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>>
>>
>>
>
> --
> Michael Droettboom
> Science Software Branch
> Operations and Engineering Division
> Space Telescope Science Institute
> Operated by AURA for NASA
-- 
Reinier Heeres
Tel: +31 6 10852639

Nevermind -- this is in Agg 2.4 as well. Don't know why I missed it 
yesterday. I'll have a look into this to see how well we can integrate it.
Cheers,
Mike
Michael Droettboom wrote:
> Ah -- I didn't look at Agg 2.5 at all because of the licensing issues. 
> Isn't this a no-go for us because it's GPL'd?
>
> Cheers,
> Mike
>
> John Hunter wrote:
> 
>> On Thu, Aug 6, 2009 at 1:53 PM, Michael Droettboom<md...@st...> wrote:
>>
>> 
>> 
>>> Even with this, the gradient infrastructure in Agg assumes a one-dimensional
>>> map, and here we need to at least interpolate between the three points of a
>>> triangle. It's not impossible, as it's easy enough to make a custom shader,
>>> it's just that the gradient code won't help us.
>>> 
>>> 
>> I checked in with the antigrain mailing list, as was pointed to
>> examples/gouraud.cpp. This looks like what we want, no?
>>
>> wget http://www.antigrain.com/agg-2.5.tar.gz
>> tar xvfz agg-2.5.tar.gz
>> cd agg-2.5
>> make
>> cd examples/X11/
>> make gouraud
>> ./gouraud
>> 
>>
>> ------------------------------------------------------------------------
>>
>> 
>
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Ah -- I didn't look at Agg 2.5 at all because of the licensing issues. 
Isn't this a no-go for us because it's GPL'd?
Cheers,
Mike
John Hunter wrote:
> On Thu, Aug 6, 2009 at 1:53 PM, Michael Droettboom<md...@st...> wrote:
>
> 
>> Even with this, the gradient infrastructure in Agg assumes a one-dimensional
>> map, and here we need to at least interpolate between the three points of a
>> triangle. It's not impossible, as it's easy enough to make a custom shader,
>> it's just that the gradient code won't help us.
>> 
>
> I checked in with the antigrain mailing list, as was pointed to
> examples/gouraud.cpp. This looks like what we want, no?
>
> wget http://www.antigrain.com/agg-2.5.tar.gz
> tar xvfz agg-2.5.tar.gz
> cd agg-2.5
> make
> cd examples/X11/
> make gouraud
> ./gouraud
> 
>
> ------------------------------------------------------------------------
>
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Thu, Aug 6, 2009 at 1:53 PM, Michael Droettboom<md...@st...> wrote:
> Even with this, the gradient infrastructure in Agg assumes a one-dimensional
> map, and here we need to at least interpolate between the three points of a
> triangle. It's not impossible, as it's easy enough to make a custom shader,
> it's just that the gradient code won't help us.
I checked in with the antigrain mailing list, as was pointed to
examples/gouraud.cpp. This looks like what we want, no?
wget http://www.antigrain.com/agg-2.5.tar.gz
tar xvfz agg-2.5.tar.gz
cd agg-2.5
make
cd examples/X11/
make gouraud
./gouraud

On Thu, Aug 6, 2009 at 11:31 PM, Ryan Wagner<rw...@vn...> wrote:
>>Does your workaround work for all supported backends, and with alpha
>>less than 1? If so, what is it?
>
> I believe it will... it is to set the edgecolors (RGBA) of the polygons to that of the facecolors. I will certainly test it on all backends and with several test cases before submitting anything, but it looks promising so far!
I agree with Eric that lw=0 should mean draw no line at all. In
postscript, linewidth=0 means "draw the thinnest line you can" but
early on we overrode this behavior to make the postscript backend
consistent with other mpl backends, so that linewidth=0 means draw no
line at all. I think 3D should be consistent with this. But setting
the edgecolors=facecolors should be fine too -- either of these or
both can be tested to see what gives the best behavior at the edges.
JDH

Jae-Joon Lee wrote:
> My understanding is that MOVETO in the middle of the path serve as a
> CLOSEPOLY when the path is filled. So, I don't think it actually
> matters how holes are connected each other. And as you can see, the
> largest hole is actually composed of three different polygons that
> overlaps, and the funny pattern is due to this overlaps.
> 
> The attached is my attempt to solve this problem. "remove_cuts"
> removes the cuts in a way that a hole becomes a single closed polygon,
> although I'm not sure if the code is rigorous enough. It seems to work
> okay for your sample data. It assumes that cuts are always vertical
> lines but this assumption can be dropped if we do bookkepping of all
> the path segments.
> I hope the code turns out to be work okay in general.
> 
> Ideally, it would be better if something similar would be done inside
> the contouring routine.
JJ,
Thank you. In fact, earlier today I wrote a python class that handles 
the reorganization of the paths, and it seems to work fine--but it is 
much too slow for complicated contour plots. Therefore I started on a C 
implementation inside cntr.c, directly generating the verts and codes 
that will be input to Path. I think I have the main structure in place, 
but finishing and debugging will take some time. I hope to be able to 
commit it in a few days.
Eric
> 
> -JJ
> 
> 
> 
> On Thu, Aug 6, 2009 at 1:58 PM, Eric Firing<ef...@ha...> wrote:
>> Mike,
>>
>> When I eliminate the cuts from filled contour paths, I do find pathological
>> cases where the filling works correctly with the cuts in place, but not
>> without them. Attached are a data file and a script to plot it,
>> illustrating the problem. Is this due to a known limitation of filled
>> paths? In the example, the top two holes are connected to the lower hole,
>> instead of being connected directly to the outer boundary of the filled
>> region. Is this illegal? If so, I think we are stuck, because rearranging
>> the paths that cntr makes to eliminate this type of case would likely be
>> very difficult.
>>
>> Eric
>>
>> ------------------------------------------------------------------------------
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
>> trial. Simplify your report design, integration and deployment - and focus
>> on
>> what you do best, core application coding. Discover what's new with
>> Crystal Reports now. http://p.sf.net/sfu/bobj-july
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>>
>>
>> ------------------------------------------------------------------------
>>

My understanding is that MOVETO in the middle of the path serve as a
CLOSEPOLY when the path is filled. So, I don't think it actually
matters how holes are connected each other. And as you can see, the
largest hole is actually composed of three different polygons that
overlaps, and the funny pattern is due to this overlaps.
The attached is my attempt to solve this problem. "remove_cuts"
removes the cuts in a way that a hole becomes a single closed polygon,
although I'm not sure if the code is rigorous enough. It seems to work
okay for your sample data. It assumes that cuts are always vertical
lines but this assumption can be dropped if we do bookkepping of all
the path segments.
I hope the code turns out to be work okay in general.
Ideally, it would be better if something similar would be done inside
the contouring routine.
-JJ
On Thu, Aug 6, 2009 at 1:58 PM, Eric Firing<ef...@ha...> wrote:
> Mike,
>
> When I eliminate the cuts from filled contour paths, I do find pathological
> cases where the filling works correctly with the cuts in place, but not
> without them. Attached are a data file and a script to plot it,
> illustrating the problem. Is this due to a known limitation of filled
> paths? In the example, the top two holes are connected to the lower hole,
> instead of being connected directly to the outer boundary of the filled
> region. Is this illegal? If so, I think we are stuck, because rearranging
> the paths that cntr makes to eliminate this type of case would likely be
> very difficult.
>
> Eric
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

> On Thu, Aug 6, 2009 at 4:11 PM, Ryan Wagner<rw...@vn...> wrote:
>> When I set the linewidths to 0 (in the patch I'm working on) I get an image looking like this:
>>
>> http://static.ryanjwagner.com/mpl_patches/lw0.png
>>
>> I don't think this looks correct to me, as I can still see the grid. I have a workaround in place so if linewidth=0 then the image looks like this:
>>
>Does your workaround work for all supported backends, and with alpha
>less than 1? If so, what is it?
I believe it will... it is to set the edgecolors (RGBA) of the polygons to that of the facecolors. I will certainly test it on all backends and with several test cases before submitting anything, but it looks promising so far!
>> http://static.ryanjwagner.com/mpl_patches/lw0_fix.png
>>
>> Would you agree that this should be the expected functionality or should I leave this alone, or should it be a new keyword?
>
> Perhaps leaving it as it is today for lw=0, but having your behavior
> be the result for lw=None? I can see people wanting the very fine
> grid that lw=0 gives today, and lw=None to me seems to be very
> explicitly saying 'no lines'.
>Except that in typical mpl usage, None means use a default.
>For colors, 'none' (a string) means no color, so a line should not be
>drawn. Elsewhere in mpl, lw=0 also means "don't draw it at all", so it
>seems right to me that it should do the same for 3-D.
Seems like we need more discussion about this... anyone else want to chime in? I do like Fernando's idea if only to not break backwards compatability...
>Eric
>
> Just an idea...
>
> Cheers,
>
> f
>
> ps - Congrats to all on the release! You've all done an absolutely
> terriffic job, and the benefits are already becoming obvious with
> these new ideas and contributions. We'll have to celebrate at scipy
> :)
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Fernando Perez wrote:
> On Thu, Aug 6, 2009 at 4:11 PM, Ryan Wagner<rw...@vn...> wrote:
>> When I set the linewidths to 0 (in the patch I'm working on) I get an image looking like this:
>>
>> http://static.ryanjwagner.com/mpl_patches/lw0.png
>>
>> I don't think this looks correct to me, as I can still see the grid. I have a workaround in place so if linewidth=0 then the image looks like this:
>>
Does your workaround work for all supported backends, and with alpha 
less than 1? If so, what is it?
>> http://static.ryanjwagner.com/mpl_patches/lw0_fix.png
>>
>> Would you agree that this should be the expected functionality or should I leave this alone, or should it be a new keyword?
> 
> Perhaps leaving it as it is today for lw=0, but having your behavior
> be the result for lw=None? I can see people wanting the very fine
> grid that lw=0 gives today, and lw=None to me seems to be very
> explicitly saying 'no lines'.
Except that in typical mpl usage, None means use a default.
For colors, 'none' (a string) means no color, so a line should not be 
drawn. Elsewhere in mpl, lw=0 also means "don't draw it at all", so it 
seems right to me that it should do the same for 3-D.
Eric
> 
> Just an idea...
> 
> Cheers,
> 
> f
> 
> ps - Congrats to all on the release! You've all done an absolutely
> terriffic job, and the benefits are already becoming obvious with
> these new ideas and contributions. We'll have to celebrate at scipy
> :)
> 
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with 
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On Thu, Aug 6, 2009 at 4:11 PM, Ryan Wagner<rw...@vn...> wrote:
> When I set the linewidths to 0 (in the patch I'm working on) I get an image looking like this:
>
> http://static.ryanjwagner.com/mpl_patches/lw0.png
>
> I don't think this looks correct to me, as I can still see the grid. I have a workaround in place so if linewidth=0 then the image looks like this:
>
> http://static.ryanjwagner.com/mpl_patches/lw0_fix.png
>
> Would you agree that this should be the expected functionality or should I leave this alone, or should it be a new keyword?
Perhaps leaving it as it is today for lw=0, but having your behavior
be the result for lw=None? I can see people wanting the very fine
grid that lw=0 gives today, and lw=None to me seems to be very
explicitly saying 'no lines'.
Just an idea...
Cheers,
f
ps - Congrats to all on the release! You've all done an absolutely
terriffic job, and the benefits are already becoming obvious with
these new ideas and contributions. We'll have to celebrate at scipy
:)