Discussed this on the call today and there was some interest in pursuing the class mixin idea here to try and make the multiple-inheritance a little bit more manageable.

We want the coordinate handling ofQuadMesh, but the drawing capability ofPolyCollection. The mixin will likely look like some 2D coordinate handling class without a.draw() method. Then the currentQuadMesh would still implement its own.draw() relying on the coordinate handling from the mixin. This would eliminate some of the confusion for where the coordinate handling/drawing are coming from if the mixin is designed to only handle the 2D coordinate work and not the drawing.

classQuadCoordinatesMixindef__init__(self,coordinates):self._coordinates=coordinatesdefset_array(self,A):# current quadmesh array validation logic for the shapesdefget_coordinates(self):returnself._coordinates# ... other (static)methods like get/set_paths()?classQuadMesh(QuadCoordinatesMixin,Collection):# override draw/path methods from CollectionclassPolyQuadMesh(QuadCoordinatesMixin,PolyCollection):# override draw/path methods from PolyCollection to utilize 2D coordinates from the mixin

Other thoughts and comments on the design are more than welcome!

This seems to be in draft state, but feel free to move back...

@rcomer, I think it was fairly straight forward to support RGB(A) here as well. I just pushed a new commit that seems to work well with that case, although I didn't add any tests yet.

@efiring, pinging you to get your thoughts on this restructure again.

I tried this out with Cartopy, and it breaks the usage there because Cartopy expects a masked array to be compressed and subsequently passes an array toset_array based on that assumption. Here is a simple example:

importmatplotlib.pyplotaspltimportnumpyasnparr=np.ma.array(np.arange(12).reshape(3,4),mask=[[0,0,0,0],                                                     [1,1,1,1],                                                     [0,1,0,1]])fig,ax=plt.subplots()pc=ax.pcolor(arr)pc.set_array(np.ones(6))plt.show()

With v3.7 andmain, this gives

With this branch we get

ValueError: For X (5) and Y (4) with flat shading, A should have shape (3, 4, 3) or (3, 4, 4) or (3, 4) or (12,), not (6,)

There is also handling in Cartopy that expects to get the compressed array out ofget_array. It's very easy tofix all of this in Cartopy, but I wonder if there should be a deprecation pathway?

I'm not sure if the "compressed" nature of the output is a feature or a bug... A similar "bug" for scatter changing the size of the array and the colors#9891. In Cartopy, we decided to work with the compression, but I really don't think that is the right way to do it because you have to keep track of everything externally and remember how you compressed your masks each time. I've just pushed up a new commit that changes the number of polys based on the masked array passed intoset_array() and grows/shrinks appropriately.

One thing this does bring up though is that there is an inconsistency between thearray() methods which assume 2d in this PR andfacecolors() /hatch etc.. that are all on the flattened PolyCollection with masked elements removed. So I am making a bit of an assumption that the array is the quantity of importance to the MeshCollection and not the others...

I checked seaborn and Astropy and didn't see any usage ofpcolor(), so I am guessing this is pretty limited in actual impacted users.

I think the compression is a misfeature, an unfortunate historical artifact, so the question is not whether to keep it in the long run but whether to try to support it through a deprecation cycle. I haven't looked closely, but it seems like temporarily continuing to allow the compressed 1-D input (with a deprecation warning) could be done now that you are saving the mask.

I completely agree that it's better without the compression. It's just the transition that might be a problem. This will break users ofGeoAxes.pcolormesh with wrapping until they get an updated Cartopy. (Apologies if you already thought of that and have plans for a quick release of Cartopy).

Thanks for both of your suggestions! I added a deprecation warning for when the compressed size of the array is used. We still defer to super's set_array() by making our own filled array, so this special casing just needs to be removed in a couple of releases.

I'm not at all sure it would be worthwhile, but it would be possible to give the_MeshData.get_facecolor etc. methods aflatten kwarg so that they would flatten for PolyQuadMesh, but maintain their dimensions for QuadMesh, making it more consistently 2-D.

I'm not at all sure it would be worthwhile, but it would be possible to give the _MeshData.get_facecolor etc. methods a flatten kwarg so that they would flatten for PolyQuadMesh, but maintain their dimensions for QuadMesh, making it more consistently 2-D.

I agree it would be nicer for consistency and that is actually the way it is on the current main branch after#24638. But, a few downstream packages test againstget_facecolors() and thus expect the flattened shape (apparentlyget_array() is not as much of an issue downstream which I guess makes some sense in they already know the data they passed in so don't need to test against that yet again). The discussion over flattening or not for QuadMesh is in this issue:#25162

So the current state of this PR would have array/data as 2d arrays, but facecolors and edgecolors (and all other collection properties) are always flattened. I think this is reasonable for taking incremental steps forward here and we can approach turning more collection properties into 2d meshes in future PRs if we think it is worthwhile.

@jklymak I added two new notes, one for the deprecation and one trying to give a description of thepcolor() capabilities including masking and hatching in a "whats new" entry. Open to other suggestions if you think something else would be better here.

I thinkhttps://matplotlib.org/stable/api/_as_gen/matplotlib.pyplot.pcolormesh.html#differences-pcolor-pcolormesh needs to be modified, and that is probably a good place to explain a bit more about what is going on here.

Thanks for pointing that out, I updated that with a new sentence at the end and updated the mentions of PolyCollection to point to PolyQuadMesh now.

I think this is ready to go?

@jklymak It looks like this is failing CI on the main branch. Not immediately obvious to me what the issue is.

Can you elaborate on what broke

Here's thefailing run, on the test added in#26232:https://dev.azure.com/matplotlib/matplotlib/_build/results?buildId=34579&view=logs&jobId=a13b2278-df49-54cc-15b0-65b285122fc1&j=a13b2278-df49-54cc-15b0-65b285122fc1&t=34567d39-342c-50d5-0018-0027f0fe0383

The problem is that the x- and y-values in the test have alternating columns that are all masked, so become completely masked arrays within_interp_grid. Previouslynp.hstack was used, which would have stripped the mask. But now we're usingnp.ma.hstack.

I guess the question is whether the test represents a realistic use-case.

I'm confused why this was passing CI before?

I'm confused why this was passing CI before?

Having slept on it, I realise it shouldn't have. I have opened#26273 to modify the test.