Seems like all tests were OK?

Maybe add a test like one of the examples in #26972 though?

Seems like all tests were OK?

Maybe add a test like one of the examples in #26972 though?

That's weird, numerous tests are failing on my machine test_pathes, test_path, test_axes... They are all image comparison tests complaining "image not close" but the difference are all black (according to human eyes) Are we doing image comparison tests differently on CI?

mpl version is 3.9.0.dev356+g19c0e07558

Should the test be an image comparison test that with a baseline image? I haven't think about a way that we don't need to add a image

Does the tests pass on main for you? A common reason for failing tests is font issues (one reason that MPL pin freetype to an old version is subtle differences in the exact rendering). A consequence is that it may be hard to generate test images on such an install (as they will maybe fail on the CI, but worth trying, it is actually possible to download the CI-generated image from the artifact and use that if it is a problem).

Another reason is that a different processor architecture is used, which may lead to floating-point differences. Usually we compensate for that in the tests, e.g.

But considering your multiple failures I'd guess freetype.

Does the tests pass on main for you? A common reason for failing tests is font issues (one reason that MPL pin freetype to an old version is subtle differences in the exact rendering). A consequence is that it may be hard to generate test images on such an install (as they will maybe fail on the CI, but worth trying, it is actually possible to download the CI-generated image from the artifact and use that if it is a problem).

Another reason is that a different processor architecture is used, which may lead to floating-point differences. Usually we compensate for that in the tests, e.g.

matplotlib/lib/matplotlib/tests/test_contour.py

Lines 384 to 387 in 1536245

	@image_comparison(
	['contour_addlines.png'], remove_text=True, style='mpl20',
	tol=0.15 if platform.machine() in ('aarch64', 'ppc64le', 's390x')
	else 0.03)

But considering your multiple failures I'd guess freetype.

Thanks for the help! There still test failures on main (I just assumed that they will work...) I setup the dev environment with conda following "Setting up Matplotlib for development", so I have no ida about where the font issues come from?

My understanding of the problem is that:

• we always try to draw an arc less than or equal to 360 in the clockwise direction
• to sort this out we subtract the extra multiples of 360 off of the second angle
• if the second angle is now less than the first, assume they are "equal" and add 360 back to the second so we go all the way around
• in some cases when they are "equal" the floating point error falls the other way and it looks like the user asked for (0, 360 + delta) which we want to normalize to (0, delta) when the user wanted a full circle.

I don't think that this is quite the right fix. The behavior we want is:

• if theta1 == theta2 -> do nothing
• if theta1 - theta2 < 360 -> do nothing
• if theta2 == theta1 + 360 + non-epsilon -> normalize to the shortest way around
• if theta2 == theta1 + 360*n + epsilon -> draw a complete circle

so I think the test is:

• do we have a "winding"
  • if so, is it "close" to an integer number -> then draw a full circle
  • if not, make no changes