Note that "segment" is the term for one "step" (c.f.https://matplotlib.org/devdocs/api/path_api.html#matplotlib.path.Path.iter_segments)

Edit: I've just read one maybe "each LINETO step ..."

Not checked, but what about CLOSEPOLY? That should also be sub sampled.

It can go wrong. Adapting the example fromhttps://matplotlib.org/stable/gallery/shapes_and_collections/compound_path.html

importmatplotlib.pyplotaspltfrommatplotlib.patchesimportPathPatchfrommatplotlib.pathimportPathcodes= [Path.MOVETO]+ [Path.LINETO]*2+ [Path.CLOSEPOLY]vertices= [(4,4), (5,5), (5,4), (0,0)]path=Path(vertices,codes)pathpatch=PathPatch(path,facecolor='none',edgecolor='blue',linewidth=3,label='original')pathpatch2=PathPatch(path.interpolated(2),facecolor='none',edgecolor='red',linewidth=3,linestyle='dashed',label='interpolated')fig,ax=plt.subplots()ax.add_patch(pathpatch)ax.add_patch(pathpatch2)ax.autoscale_view()ax.legend()plt.show()

The vertex corresponding toCLOSEPOLY is not correctly ignored here; it should be interpolated from the previous point to the first point in the path (i.e., the most recentMOVETO or the first point in the whole thing.)

I am assuming that after splitting byMOVETO, anyCLOSEPOLY will be at the end of the path. Is that correct?

It looks like_iter_connected_components only splits onMOVETO, so it wouldn't noticeCLOSEPOLY. I'm not sure what happens to aPath withCLOSEPOLY stuck in the middle.

A CLOSEPOLY the middle can only happen if it was not followed by a MOVETO in the original path. But that means you closed a shape, and continue to draw from that position. People would likely just use LINETOs in such a case, But AFAIK there's nothing in the rules prohibitingLINETO, CLOSEPOLY, LINETO, and there could be rare cases where it makes sense/could happen.

That said, I haven't checked what we actually do here and whether that pattern renders reasonably.

Hmmmm

importmatplotlib.pyplotaspltfrommatplotlib.patchesimportPathPatchfrommatplotlib.pathimportPathcodes= [Path.MOVETO]+ ([Path.LINETO]*2+ [Path.CLOSEPOLY])*2vertices= [(4,4), (5,5), (5,4), (0,0), (3,3), (4,3), (0,0)]path=Path(vertices,codes)pathpatch=PathPatch(path,facecolor='none',edgecolor='blue',linewidth=3,label='original')pathpatch2=PathPatch(path.interpolated(2),facecolor='none',edgecolor='red',linewidth=3,linestyle='dashed',label='interpolated')fig,ax=plt.subplots()ax.add_patch(pathpatch)ax.add_patch(pathpatch2)ax.autoscale_view()ax.legend()plt.show()

It seems that the rendering at least handles internalCLOSEPOLY's. So probably we should handle them here too.

With latest update

Edit: given the axes limits here go down beyond (0,0), I guess that whatever tellsautoscale the extent of the path also does not know to ignoreCLOSEPOLY.

Edit: given the axes limits here go down beyond (0,0), I guess that whatever tellsautoscale the extent of the path also does not know to ignoreCLOSEPOLY.

I'd say this is a separate topic. Without checking: I suspect that autoscale just takes all the points, no matter what the associated code is (likely also the control points for curve).

At least forCLOSEPOLY people can work around this by using existing coordinates.

I'd say this is a separate topic.

Sure, that was very much an aside - not proposing to investigate it here.

Test a compound path with multiple closepolys by doubling this again similar to your above test to make sure the implementation handles multiple MOVETOs and CLOSEPOLYS together?

I think this patch is not sufficient if you have a path with mixtures of CLOSEPOLY AND MOVETO. The MOVETO creates a new separate separate component with a starting point that is generally different fromvertices[0].

Maybe a variation of_iter_connected_components is the way to go?

But if we got to here, we have no internalMOVETO's because we already split on them and called the function again on the subpath. I think this case is covered by the newtest_interpolated_moveto_closepoly.

Yes, you are right.