-
-
Notifications
You must be signed in to change notification settings - Fork 7.9k
FIX: colorbar placement in constrained layout #11648
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FIX: colorbar placement in constrained layout #11648
Conversation
6a70f48
to
8f20012
Compare
|
6a67460
to
0e482e3
Compare
Re milestoning as a bug fix. The behaviour here is much better than in 3.0.0 |
cm = ['RdBu_r', 'viridis'] | ||
for nn in range(2): | ||
for mm in range(2): | ||
ax = axs[mm, nn] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe use row, col
instead of mm, nn
.
# ``constrained_layout=True`` | ||
|
||
fig, axs = plt.subplots(3, 3, constrained_layout=True) | ||
for ax in axs.flatten(): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would use ax.flat
. While flatten()
reshapes the array, flat
directly returns an iterator over the array, which is all we are needing here.
# For the `~.axes.Axes.pcolormesh` kwargs (``pc_kwargs``) we use a | ||
# dictionary. Below we will assign one colorbar to a number of axes each | ||
# containing a `~.cm.ScalarMappable`; specifying the norm and colormap | ||
# ensuresthe colorbar is accurate for all the axes. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
missing space
# | ||
# ``constrained_layout`` usually adjusts the axes positions on each draw | ||
# of the figure. If you want to get the spacing provided by | ||
# ``constrained_layout`` but then not have it update, then do the initial |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
leave out the "then" before "do". This sentence has too much "then" 😄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks - I took out the first "then" so it now reads:
# If you want to get the spacing provided by
# ``constrained_layout`` but not have it update, then do the initial
# draw and then call ``fig.set_constrained_layout(False)``.
0e482e3
to
6d201de
Compare
Thanks for the careful review @timhoffm |
6d201de
to
c3a17ab
Compare
c3a17ab
to
f4438fb
Compare
I only had a quick look through the code, too quick to give a green checkmark here already, but in principle this looks good and it's definitely correct to not let the two cases of contrained layout=True or False differ substantially. Now this PR introduces a new "Placing colorbars" example, which is a great idea. If that is the place to look for how to place colorbars in matplotlib, it's not yet complete, since there are lots of other ways, mostly via the
Seeing how long that list has become, it might as well be suitable as tutorial? |
My proposal would be for this PR to go in, and then if someone wants to add a couple more examples to the new example file, that would be great. I'd love to see how |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After going through this in more detail, I tried to construct cases for which this would fail. Turns out I didn't find any. So I agree that this should go in to be able to move on.
Great - any of those cases you think would be useful as tests we can add. Certainly I could break it in the future! |
…648-on-v3.0.x Backport PR #11648 on branch v3.0.x (FIX: colorbar placement in constrained layout)
The test added here seems to have broken on Travis |
Actually, it was already broken when it was merged, but it's been 9 days since the PR build, so I'm not certain what might have affected it. |
The test passes locally on master... |
@QuLogic 3.1 tests are passing on Master. Was it 3.0.x tests that have trouble? |
Well, I'm not sure what happened; it seems to have magically fixed itself. It was definitely failing right after merging this PR and also after merging the fix from #12366 that otherwise broke things. |
@jklymak Since you asked for special cases for potential tests: The following produces a rather strange figure
But constrainedlayout is perfectly capable of handling it: In contrast, when you add another axes later on, it'll overlap, both with and without constrained layout.
Not sure if any of those should be considered valid or useful though. |
Those were brain teasers. I'm OK w/ the first case inconsistency. Colorbar steals space from the axes you list, and there is no way for the third axes to know space was stolen from the other two without a draw-time hook like ConstrainedLayout. The second case is a bit more concerning; I'd have thought ideally CL would forget about the lost axes, and move the colorbar over to the left. But... that's a pretty hard pathological case, so I'm not going to worry about it, unless there is a good use case for it, in which case it may be worth the effort. Thanks a lot for sending these! Great examples... |
PR Summary
Closes #11641
Previously, while using
constrained_layout
putting a colorbar on a figure put the colorbar to the right (or other location) of the parent gridspec of the axes specified.However, the non-
constrained_layout
way of doing this would just put to the right of the listed axes.This PR makes the
constrained_layout
behaviour the same as non-constrained_layoutBefore:
Behaviour of where first colorbar went changed significantly under
constrained_layout
After
Behaviour more consistent...
PR Checklist