Unfortunately, arrow() is not a good way to draw the arrow head. It is affected by Axes aspect ration and limits (see the note at the bottom of https://matplotlib.org/stable/api/_as_gen/matplotlib.axes.Axes.arrow.html). Likely, the clean solution is to draw a single trangular marker and rotate it according to https://matplotlib.org/stable/gallery/lines_bars_and_markers/marker_reference.html#advanced-marker-modifications-with-transform.

FYI, the "Closes #25477" needs to go in the body of the PR description to automatically link, not the title. I've gone ahead and added it for this one

I changed the demo in the last commit to use paches.Ellipse and a marker rotated by transform.Affine2D.

One example almost looks a little sad. Do you want me to add anything more?

How do I solve the failed checks? @matplotlib/developers

How do I solve the failed checks? @matplotlib/developers

The failures in the OSX build pipeline are unrelated to this PR and can be ignored.

@timhoffm Thanks for approving! How is responsible to do the Release Note actions metioned by GitHub actions? Or is there something else for me to do?

How is responsible to do the Release Note actions metioned by GitHub actions? Or is there something else for me to do?

If you've got the time, please write release notes about the new functions-otherwise I put on the new feature label so we can find this at release time and hopefully catch that the notes are missing.

They can be really simple-something like https://github.com/matplotlib/matplotlib/blob/main/doc/users/next_whats_new/get_suptitle.rst

Ellipse.get_vertices() and Ellipse.get_co_vertices()
These methods return the vertices and co vertices of the Ellipse

I think it could be implemented as get_corners is:

    def get_corners(self):
        """
        Return the corners of the ellipse bounding box.

        The bounding box orientation is moving anti-clockwise from the
        lower left corner defined before rotation.
        """
        return self.get_patch_transform().transform(
            [(-1, -1), (1, -1), (1, 1), (-1, 1)])
            
    def get_vertices(self):
        """
        Return the vertices and covertices of the ellipse.

        ...Maybe look at order that would be desired
        """
        return self.get_patch_transform().transform(
            [(0, 1), (1, 0), (0, -1), (-1, 0)])

I think the distinction between "vertex" and "co-vertex" is unclear here...

By the source (wiki article) listed, I believe that a "vertex" should be on the line defined by the foci, and a "co-vertex" should be on the perpendicular bisector of the foci.

Here, we define the ellipse by its bounding box, rather than by its foci.

If it is defined with height > width, then I think the definition would be reversed from if height < width, but the computation does not account for that.

Additionally, "left" vs "right" doesn't necessarily make sense (They could be aligned along the vertical axis, and even if they aren't then it's not really adding anything to the definition)

Perhaps this could be implemented as a single function that returns all four points, without necessarily specifying order?

Finally, should probably have a .. versionadded:: 3.8 directive in the docstring if we are trying to do that.

I agree by defining width and height it is not clear which is the minor or major axis. But I understand the definiton of vertex and co-vertex as the end points of such axes not related to the foci!?

Would it be clear if depending on the length of the major and minor axes the vertex are returned?

I think the distinction between "vertex" and "co-vertex" is unclear here...

By the source (wiki article) listed, I believe that a "vertex" should be on the line defined by the foci, and a "co-vertex" should be on the perpendicular bisector of the foci.

Here, we define the ellipse by its bounding box, rather than by its foci.

If it is defined with height > width, then I think the definition would be reversed from if height < width, but the computation does not account for that.

Additionally, "left" vs "right" doesn't necessarily make sense (They could be aligned along the vertical axis, and even if they aren't then it's not really adding anything to the definition)

Perhaps this could be implemented as a single function that returns all four points, without necessarily specifying order?

Finally, should probably have a .. versionadded:: 3.8 directive in the docstring if we are trying to do that.

I agree by defining width and height it is not clear which is the minor or major axis. But I understand the definiton of vertex and co-vertex as the end points of such axes not related to the foci!?

Would it be clear if depending on the length of the major and minor axes the vertex are returned? Circle of course is a special case...

Perhaps this could be implemented as a single function that returns all four points, without necessarily specifying order?

@ksunden I believe it's important to be able to distinguish between the vertices and covertices easily. A single function makes this hard (even if it had a guarantee on the order). I therefore believe that the two separate functions are the right API choice.

I agree by defining width and height it is not clear which is the minor or major axis. But I understand the definiton of vertex and co-vertex as the end points of such axes not related to the foci!?

I mean, the foci definition is exactly the same.

From the wiki article, section "Definition as a locus of points":

The line through the foci is called the major axis, and the line perpendicular to it through the center is the minor axis.

I do stand by that computing using the transform as is done for the get_corners method is still possible and cleaner:

def get_vertices(self):
    if self.width < self.height:
        ret = self.get_patch_transform().transform([(0, 1), (0, -1)])
    else:
        ret = self.get_patch_transform().transform([(1, 0), (-1, 0)])
    return [tuple(x) for x in ret]

def get_co_vertices(self):
    if self.width < self.height:
        ret = self.get_patch_transform().transform([(1, 0), (-1, 0)])        
    else:
        ret = self.get_patch_transform().transform([(0, 1), (0, -1)])
    return [tuple(x) for x in ret]

I will also point out that the Ellipse patch already has a get_verts method (via Patch, though it is related to the Bezier segments used to approximate the ellipse) and find this a potentially significant point of confusion. I will defer to @timhoffm for whether or not that name collision is a significant concern, though.

I agree by defining width and height it is not clear which is the minor or major axis. But I understand the definiton of vertex and co-vertex as the end points of such axes not related to the foci!?

I mean, the foci definition is exactly the same.

From the wiki article, section "Definition as a locus of points":

The line through the foci is called the major axis, and the line perpendicular to it through the center is the minor axis.

I do stand by that computing using the transform as is done for the get_corners method is still possible and cleaner:

def get_vertices(self):
    if self.width < self.height:
        ret = self.get_patch_transform().transform([(0, 1), (0, -1)])
    else:
        ret = self.get_patch_transform().transform([(1, 0), (-1, 0)])
    return [tuple(x) for x in ret]

def get_co_vertices(self):
    if self.width < self.height:
        ret = self.get_patch_transform().transform([(1, 0), (-1, 0)])        
    else:
        ret = self.get_patch_transform().transform([(0, 1), (0, -1)])
    return [tuple(x) for x in ret]

I will also point out that the Ellipse patch already has a get_verts method (via Patch, though it is related to the Bezier segments used to approximate the ellipse) and find this a potentially significant point of confusion. I will defer to @timhoffm for whether or not that name collision is a significant concern, though.

Ok, I understand. get_patch_transform().transform() is doing the same thing. So it makes it cleaner. Didn't know that methods. Thanks.

I will also point out that the Ellipse patch already has a get_verts method (via Patch, though it is related to the Bezier segments used to approximate the ellipse) and find this a potentially significant point of confusion. I will defer to @timhoffm for whether or not that name collision is a significant concern, though.

The naming similarity is not so nice but it's the best we can do: Changing the existing API get_verts does not make sense. The technical names for the points here are vertex and co-vertex. We should use them for clarity.

My approval still stands.