Thread: [matplotlib-devel] path unit_* methods: CLOSEPOLY?

Mike,

Is there any reason why the Path.unit_* methods shouldn't include the 
codes, so that they can all have CLOSEPOLY?  Or shouldn't they at least 
have a kwarg to allow that as an option?  In working on patch drawing 
via bar(), I noticed that the rectangle outline is not closing properly, 
with the same rounded join as at the other 3 corners.  It isn't apparent 
unless you set a large linewidth.

Or is there a better way to ensure that polygons close correctly?

Eric

On 08/14/2010 07:22 PM, Eric Firing wrote:
> Mike,
>
> Is there any reason why the Path.unit_* methods shouldn't include the 
> codes, so that they can all have CLOSEPOLY?  Or shouldn't they at 
> least have a kwarg to allow that as an option?  In working on patch 
> drawing via bar(), I noticed that the rectangle outline is not closing 
> properly, with the same rounded join as at the other 3 corners.  It 
> isn't apparent unless you set a large linewidth.
>
> Or is there a better way to ensure that polygons close correctly?

I don't think there's a better way.  The renderer can't assume CLOSEPOLY 
at the end, obviously, because it may in fact by a line and not a filled 
shape.

I think this was left out just as shorthand (not having a codes array 
makes things a little faster, too), but I think for correctness the 
unit_* methods should have explicit codes arrays with CLOSEPOLYs.  I'll 
go ahead and fix this.

Mike

-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

Michael Droettboom wrote:
> On 08/14/2010 07:22 PM, Eric Firing wrote:
>   
>> Mike,
>>
>> Is there any reason why the Path.unit_* methods shouldn't include the 
>> codes, so that they can all have CLOSEPOLY?  Or shouldn't they at 
>> least have a kwarg to allow that as an option?  In working on patch 
>> drawing via bar(), I noticed that the rectangle outline is not closing 
>> properly, with the same rounded join as at the other 3 corners.  It 
>> isn't apparent unless you set a large linewidth.
>>
>> Or is there a better way to ensure that polygons close correctly?
>>     
>
> I don't think there's a better way.  The renderer can't assume CLOSEPOLY 
> at the end, obviously, because it may in fact by a line and not a filled 
> shape.
>
> I think this was left out just as shorthand (not having a codes array 
> makes things a little faster, too), but I think for correctness the 
> unit_* methods should have explicit codes arrays with CLOSEPOLYs.  I'll 
> go ahead and fix this.
>
> Mike
>
>   

Hi Mike, all the buildbots have errors with the
matplotlib.tests.test_simplification.test_hatch test on r8639 that
weren't there in r8635, and I think it's due to the code you committed.
Could you have a look?

(Don't worry about the doc build errors -- I think that's a bug with the
recent Sphinx 1.0.2 release, for which I have filed a report at
http://bitbucket.org/birkenfeld/sphinx/issue/501 for.)

(I was proud of all the green on the buildbot -- hopefully it won't turn
me into a chronic nag!)

-Andrew

Sorry about that.  I believe it is fixed now.

Mike

On 08/16/2010 05:54 PM, Andrew Straw wrote:
> Michael Droettboom wrote:
>    
>> On 08/14/2010 07:22 PM, Eric Firing wrote:
>>
>>      
>>> Mike,
>>>
>>> Is there any reason why the Path.unit_* methods shouldn't include the
>>> codes, so that they can all have CLOSEPOLY?  Or shouldn't they at
>>> least have a kwarg to allow that as an option?  In working on patch
>>> drawing via bar(), I noticed that the rectangle outline is not closing
>>> properly, with the same rounded join as at the other 3 corners.  It
>>> isn't apparent unless you set a large linewidth.
>>>
>>> Or is there a better way to ensure that polygons close correctly?
>>>
>>>        
>> I don't think there's a better way.  The renderer can't assume CLOSEPOLY
>> at the end, obviously, because it may in fact by a line and not a filled
>> shape.
>>
>> I think this was left out just as shorthand (not having a codes array
>> makes things a little faster, too), but I think for correctness the
>> unit_* methods should have explicit codes arrays with CLOSEPOLYs.  I'll
>> go ahead and fix this.
>>
>> Mike
>>
>>
>>      
> Hi Mike, all the buildbots have errors with the
> matplotlib.tests.test_simplification.test_hatch test on r8639 that
> weren't there in r8635, and I think it's due to the code you committed.
> Could you have a look?
>
> (Don't worry about the doc build errors -- I think that's a bug with the
> recent Sphinx 1.0.2 release, for which I have filed a report at
> http://bitbucket.org/birkenfeld/sphinx/issue/501 for.)
>
> (I was proud of all the green on the buildbot -- hopefully it won't turn
> me into a chronic nag!)
>
> -Andrew
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>    


-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA