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

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

···

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?

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

Michael Droettboom 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

···

On 08/14/2010 07:22 PM, Eric Firing wrote:

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
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