MatplotlibDeprecationWarning: shading='flat' when X and Y have the same dimensions as C is deprecated since 3.3. Either specify the corners of the quadrilaterals with X and Y, or pass shading='auto', 'nearest' or 'gouraud', or set rcParams['pcolor.shading']. This will become an error two minor releases later.
Code for reproduction
importnumpyasnpimportmatplotlib.pyplotaspltx=np.arange(10.0)
mat=np.random.randn(10, 10)
plt.contour(x, x, mat)
# for a solid colorbar:cbar=plt.colorbar()
cbar.filled=Truecbar.draw_all()
Actual outcome
Python 3.8.5 (default, Sep 4 2020, 07:30:14)
Type 'copyright', 'credits' or 'license' for more information
IPython 7.18.1 -- An enhanced Interactive Python. Type '?' for help.
In [1]: run ttt
ttt.py:11: MatplotlibDeprecationWarning: shading='flat' when X and Y have the same dimensions as C is deprecated since 3.3. Either specify the corners of the quadrilaterals with X and Y, or pass shading='auto', 'nearest' or 'gouraud', or set rcParams['pcolor.shading']. This will become an error two minor releases later.
cbar.draw_all()
In [2]: import matplotlib
In [3]: matplotlib.__version__
Out[3]: '3.3.1'
In [4]: quit
OK, so its easy to fix the above to the old behaviour. However, I strongly expect the old behaviour was incorrect and dropping the color for your highest contour value. Is that OK? Your last color was basically the color of the second to last contour.
i.e. the outline doesn't get updated when you change the axis limits. I think the outline (and patch) should instead be defined in ax.transAxes for things to work?
Oh hum. I spent about a week of Matplotlib time working on fixing all this, but its a pretty big architecture change. Someone should probably dive in and patch this for the contour case cited above for 3.3.3
Activity
ksunden commented on Sep 27, 2020
matplotlib/lib/matplotlib/colorbar.py
Line 823 in 55fb9f0
Here is the offending line
jklymak commented on Sep 28, 2020
This shouldn't be too hard to fix - someone just needs to look and see how the solid colorbar is made and make the x/y the proper length....
jklymak commented on Sep 28, 2020
OK, so its easy to fix the above to the old behaviour. However, I strongly expect the old behaviour was incorrect and dropping the color for your highest contour value. Is that OK? Your last color was basically the color of the second to last contour.
dopplershift commented on Sep 28, 2020
Well, that's ok because it matches the case with filled=False. My question would be, why does this code:
produce:

which only has 12 lines on the colorbar (and thus is already chopping the highest level).
jklymak commented on Sep 28, 2020
Is that just clipping?
dopplershift commented on Sep 28, 2020
Probably: len(cbar.lines[0].get_colors()) gives 13. If only I could get it to draw properly...I can never remember how to hack colorbar axes...
jklymak commented on Sep 28, 2020
hmmmm, are the contour axes still the old style? Because the new style should allow just setting the xlim....
dopplershift commented on Sep 28, 2020
Setting xlim/ylim on the colorbar only changes its size, it doesn't draw anything above 12.5 for me.
jklymak commented on Sep 28, 2020
Yech. Curious if it ever worked or if we (prob. me) broke something?
anntzer commented on Oct 5, 2020
My guess is that this comes from
matplotlib/lib/matplotlib/colorbar.py
Line 543 in 6970023
i.e. the outline doesn't get updated when you change the axis limits. I think the outline (and patch) should instead be defined in ax.transAxes for things to work?
jklymak commented on Oct 28, 2020
Oh hum. I spent about a week of Matplotlib time working on fixing all this, but its a pretty big architecture change. Someone should probably dive in and patch this for the contour case cited above for 3.3.3