-
-
Notifications
You must be signed in to change notification settings - Fork 7.9k
tight_layout: Use a different default gridspec #4559
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
Conversation
The python2.6 failure seems unrelated... |
I think you need to be a little bit more descriptive about what you mean by letting tight_layout do the right thing. |
I kicked the test to restart. A less intrusive patch would be to change the default value from Does this still do the right thing the user creates multiple figures using a method which does not otherwise add I am not super familiar with this section of the code base, but my knee-jerk reaction is that this patch will have nasty side effects (that we apparently don't test?). |
Here is the resulting image without the patch: and this is after the patch (which is basically looking the same as not using tight_layout): So it seems this patch corrects the picture to match the result of not using tight_layout (which I meant above with "doing the right thing"). @tacaswell: I'm unsure, if there are other cases, where I also expected side effects and wanted to post this to see some failing tests... |
A picture is worth a million words. I now see what you are talking about. What I think is happening is that the location of the colorbar axes is being defined by fractions of the figure space outside of the subplot spec system. Tight layout adjusts the spacing of items defined by the subplot spec system. So, it is completely unaware of other axes elements that were added to the figure in other ways. So, I think the important question here is whether or not this is really a bug in the first place? tight_layout is doing exactly what it is supposed to be doing -- finding an optimal layout for axes in the subplot grid spec. It just so happens that the user has other axes in the figure that are custom placed. I would argue that this actually introduces a bug, because now the colorbar is no longer placed where I told it to be. Indeed, I do know of people who like to put their colorbars in custom locations, oftentimes inside a plot area, and would be pissed to no end if tight_layout all the sudden changed this. Perhaps we need to improve the colorbar api to allow for different intentions? |
indeed... I guess I am not fully understanding what is going on here, then. |
This doesn't involve the colorbar API; the |
02fbbe3
to
9195a88
Compare
The example above was based on this example and I think that one should be(come) supported also with The updated patch looks now much nicer and The last commit adds a test for the case of one picture and a colorbar. That one is identical to the output before, but makes sure to not break it in the future. My testcase for two figures unfortunately cuts off the labels a bit, so that one is not yet fully finished for regtesting and I like to leave that for a future improvement... |
Just a ping to remind you we are alive and have not forgotten you. |
b6eb13f
to
1717f37
Compare
I am quite sure that the checks were completing. Will try to look into the failure soonish. |
It is probably the text. Sense you did this we a) now have a way to install a specific version of freetype for testing and b) have zero-tolerance testing on the image comparisons. |
c9bb7a8
to
0af60d4
Compare
Should be fine now. It took me a while to notice that |
|
Great, thanks |
The appveyor |
re appveyor: I agree :-)
-> conda can't find its packages... |
aa2acd6
to
1a3f54f
Compare
Note: instead of removing the warnings, they could be made more informative as to how make the Axes compatible with tight_layout. |
After rebasing, the new tests added above don't pass anymore. I didn't remove the warnings, I just refactored them to another place. But I'll also look into making them more informative, while at it. |
6c29ccc
to
41e6839
Compare
91d7ff0
to
a0c2b33
Compare
a0c2b33
to
b1642d5
Compare
This commit adds a default gridspec to tight_layout. It helps to build a better wimage when using tight_layout with figures that do not (yet) implement their own gridspec. This does not affect figures that do not use tight_layout and only improves the case with tight_layout at least in my testcases. The warning, that warns from the usage of figures that have no gridspec implemented is retained.
b1642d5
to
a6f88c8
Compare
6601685
to
8770e82
Compare
I'm not quite sure why this PR works, or if it does for anything other than the test. If the gridspecs don't know about each other, I'm not sure how they negotiate which should be placed where. If we changed the gridspec hierarchy so that the gridspecs knew about the figure that contains them, then we could make this all work but thats not how GridSpec currently works by default. For fun, you could try fig, axes = plt.subplots(nrows=2, sharex=True, sharey=True, constrained_layout=True)
CS = plt.contour(xi, yi, zi, 15, linewidths=0.5, colors='k')
CS = axes[1].contourf(xi, yi, zi, 15, cmap=plt.cm.rainbow,
vmax=abs(zi).max(), vmin=-abs(zi).max())
CS = axes[0].contourf(xi, yi, zi, 15, cmap=plt.cm.rainbow,
vmax=abs(zi).max(), vmin=-abs(zi).max())
cbar = fig.colorbar(CS, ax=axes, shrink=0.8)
plt.show() |
With You know for sure more about the gridspec machinery than I do. If I read the gridspec docs correctly, the gridspec of |
I'm going to close this - this just allows tight_layout to be called, but tight_layout doesn't do anything, so its better to error rather than mislead the user that something is happening. |
This commit adds a default _subplotspec to all axes, which will help with
building a better image when using tight_layout. At least in my testcase, the
images with and without tight_layout are close to identical after this commit
and it does look really odd without this default _subplotspec.
I doubt, this is the right thing to do. But if it works on a broader case of figures, we'll see if it is not a bad idea or not.
My testcase is a modified version of the
griddata_demo.py
. If this should be added to the tests let me know: