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 from https://matplotlib.org/stable/gallery/shapes_and_collections/compound_path.html

import matplotlib.pyplot as plt

from matplotlib.patches import PathPatch
from matplotlib.path import Path

codes = [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 to CLOSEPOLY is not correctly ignored here; it should be interpolated from the previous point to the first point in the path (i.e., the most recent MOVETO or the first point in the whole thing.)

I am assuming that after splitting by MOVETO, any CLOSEPOLY will be at the end of the path. Is that correct?

It looks like _iter_connected_components only splits on MOVETO, so it wouldn't notice CLOSEPOLY. I'm not sure what happens to a Path with CLOSEPOLY 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 prohibiting LINETO, 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

import matplotlib.pyplot as plt

from matplotlib.patches import PathPatch
from matplotlib.path import Path

codes = [Path.MOVETO] + ([Path.LINETO]*2 + [Path.CLOSEPOLY]) * 2
vertices = [(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 internal CLOSEPOLY'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 tells autoscale the extent of the path also does not know to ignore CLOSEPOLY.

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

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 for CLOSEPOLY 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 from vertices[0].

Maybe a variation of _iter_connected_components is the way to go?

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

Yes, you are right.