Thanks for keeping at this, does#28104 need to be merged first?

Yes, preferably, so that the changes for Patches can be accurately replicated for Collections

There is currently one test which is failing and might need a rewrite:lib/matplotlib/tests/test_axes.py::test_contour_hatching

Previous Behavior

In collections, hatchcolor is set along with edgecolor.

In the cases whereedgecolors is explicitly specified by the user,hatchcolor is set to the first color in edgecolors and it also uses the alpha value specified by the user. However, ifedgecolors is not specified,hatchcolor usesmpl.rcParams['hatch.color'] for the color, but it doesn't use the alpha value specified by the user.

New Behavior

The new implementation in this PR has hatchcolor separated from edgecolor and it uses the alpha value specified by the user, regardless of whether edgecolors is specified or not.

Reason for New Behavior

alpha works onhatchcolor whenedgecolors is specified. Therefore, I believe that it should also work whenedgecolors is not specified.

In the above test,alpha is set to 0.5. Ideally, the hatch should have an alpha value of 0.5, but it has the default alpha value of 1.0.

pinging@story645 for review

The PDF test fortest_axes.py::test_contour_hatching isn't failing, so the baseline PDF is left untouched. I suspect that this is because alpha on hatches on PDF backend isn't completely implemented and it looks like#17049 aims to fix this.

AFAICS you haven't modified the test. This would mean, whe have a change of default behavior. Can that be avoided?

I think that we can't avoid this change, because the default behavior is somewhat inconsistent, as explained in thiscomment.

(2) I suggest to modifying the test instead (likely by setting an explicit hatch color) so that the tests images do not need update. Generally, we try to use as few images as possible and changes them as a rarely as possible, because the images bloat the git repo.

I think it might be better to update the images, because it looks like the test was previously testing the incorrect behavior. I think that it is better to have the test images reflect the correct behavior, as this test covers the behavior of hatchcolors with alpha values more comprehensively than if we change the test to explicitly set the hatch color to black with alpha = 1.0.

When explicitly setting hatchcolor, I wasn't able to force alpha as 1.0 for hatchcolor without using_hatchcolors attribute.

diff --git a/lib/matplotlib/tests/test_axes.py b/lib/matplotlib/tests/test_axes.pyindex 38857e846c..5764d3fff6 100644--- a/lib/matplotlib/tests/test_axes.py+++ b/lib/matplotlib/tests/test_axes.py@@ -2651,6 +2651,9 @@ def test_contour_hatching():                 cmap=mpl.colormaps['gray'],                 extend='both', alpha=0.5)+    for c in ax.collections:+        c._hatchcolors = mpl.colors.to_rgba_array('black', 1.0)+  @image_comparison(     ['contour_colorbar'], style='mpl20',

Here is why I think that the test was previously testing the incorrect behavior:
For a stackplot, with alpha = 0.3

	Previous Behavior	New Behavior (PR)
edgecolor = 'black'
edgecolor = None

Do these changes need to be applied back to the changes in#28104 and should factoring out into a global context object + versioning be their own PR(s)?

No,#28104 is not affected, because it's not changing the backend API.

I think that if we want to move this PR forward, the realistic short-term approach is to do API support sniffing via the empty call (and not even warn on third-parties for now, at least until we can agree on the long-term plan and likely also add support for multiple hatches).

Thanks@Impaler343 for adding the API sniffing. Unfortunately this is not enough, because you choose to just not pass hatchcolors at all if they are unsupported. While the idea of just drawing single-color hatches on 3rd-party backends may be reasonable (I'm fine with that), it means that these backends will try to consult rcParams["hatch.color"] to select a color; and since#28104 they can see the new unnormalized value "edge", for which there was no support before, and they will crash there. At least this value should be normalized (e.g. to the first edgecolor, I guess); ideally if hatchcolors is not supported, the draw_path_collection call should be expanded as in ContourSet.draw to draw one path at a time.

This works now on mplcairo. Thanks for going through all the work!
I haven't carefully reviewed the implementation yet but the general approach looks fine to me. Perhaps add a note that the current new API is provisional, as I expect that it will change in the future at least to support multiple hatches as well? (I would rather only change things on mplcairo's side once multiple hatches are supported too.)

@anntzer Are there any other changes expected? Or is this ready to be merged?

I still don't really like the API but it's also unrealistic to hope for a full rewrite here, so let's go with it.

I agree that this API will need to be changed in the future.

@timhoffm any suggestions?

re: making hatchcolors optional and API compatibility:
My point of view is that the renderer API (draw_foo) is public and it is legitimate for 3rd-parties to call it directly (e.g. they can create their own artist subclasses that implement their own draw() and call draw_foo() from there. However, I guess it could also be reasonable(?), and possibly helpful for extensibility, to declare that these methods arenot for 3rd-party direct use, and that third-party artistsmust go through a builtin artist's draw to invoke the renderer's drawing functions. But that's definitely not a policy we have stated so far.

Thanks. I agreeoptional is set to begin with for compatibility.

Questions are:

• Do we want/gain anything with keyword-only? - I tend towards no.
• Do we want to evolve the API to non-optional through regular deprecation machinery? - I tend towards yes.

• Do we want/gain anything with keyword-only? - I tend towards no.

It makes it easier to later include parametersbefore it, e.g.hatches is something that's clearly missing and would be expected to come first.

• Do we want to evolve the API to non-optional through regular deprecation machinery? - I tend towards yes.

Let's not for now. As argued above I think the API introduced in this PR is actually not so great (but still the best that can be done without an in-depth reworking of draw_path_collection), so e.g. I'd rather not implement support for it at all in mplcairo (and instead rely on Matplotlib's fallback implementation) until a better API comes. Likewise I don't think we should encourage any third parties to implement it.

Thanks@r3kste for going through all the nitty gritty details with us!