Skip to content

FIX: Stop tight layout collapsing under zoom #11742

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

Closed

Conversation

jklymak
Copy link
Member

@jklymak jklymak commented Jul 23, 2018

PR Summary

Fixes #11737, and supersedes #11739

We are now consulting all axes children when doing get_tightbbox (my fault: #10682), including spines. There is some sort of problem with spines not having there transform set before draw when zoom is being used, and this leads to impossible bbox calculations. (See #11627).

This PR adopts the same soln as #11627 and disables tight_layout while zoom and pan are active. This will keep the axes the same size during interactive use, which to my mind is preferable to having the axes change size all the time. However, others may disagree w that.

This PR also has failing tight_layouts just refuse to update the axes positions, whereas before they drew a collapsed axes. Again, in my opinion, drawing something reasonable is better than drawing something that is broken.

import numpy as np
import matplotlib.pyplot as plt

fig, ax=plt.subplots()
fig.set_tight_layout(True)
plt.show()

And use the GUI to zoom. Before this PR, the axes collapsed. Now the axes doesn't change at all because zoom is active.

Note it might be nice to consider when "Zoom" is turned off to trigger a draw, then CL and TL can be made to work.

Of course the original problem is that the transform of the spines is not being set early enough. Not really sure what the soln to that is.

PR Checklist

  • Has Pytest style unit tests
  • Code is PEP 8 compliant
  • New features are documented, with examples if plot related
  • Documentation is sphinx and numpydoc compliant
  • Added an entry to doc/users/next_whats_new/ if major new feature (follow instructions in README.rst there)
  • Documented in doc/api/api_changes.rst if API changed in a backward-incompatible way

@jklymak jklymak force-pushed the fix-stop-tight-layout-collapse branch from dbe6dbc to 70e7d18 Compare July 23, 2018 02:46
@fredrik-1
Copy link
Contributor

fredrik-1 commented Jul 23, 2018

I don't like this fix but I don't know any really good solution.

It break my usual work process and I believe that the behavior is going to feel strange and inconsistent. Labels are going to be clipped sometimes when zooming and the figure is not going to update as expected if you happen to have clicked the zoom button (I believe that I usually has the zoom button active most of the time) and this could be really confusing.

I believe that tight_layout=True haven't worked as expected and that #10989 was a similar problem. The problem just became much more obvious when the spines where included in the tight_layout calculation.

I believe that a better solution would be to ignore the spines when tight_layout=True. That would probably get the same behavior as in 2.2.2. I updated #11739 to just be used with tight_layout=True

@fredrik-1 fredrik-1 mentioned this pull request Jul 23, 2018
6 tasks
@jklymak
Copy link
Member Author

jklymak commented Jul 23, 2018

It break my usual work process and I believe that the behavior is going to feel strange and inconsistent. Labels are going to be clipped sometimes when zooming and the figure is not going to update as expected if you happen to have clicked the zoom button (I believe that I usually has the zoom button active most of the time) and this could be really confusing.

Yes, thats correct - when the zoom button is active the axes resizing will stop. I think its pretty arguable whether the axes size should jump around while zooming.

An alternative approach is to take the spines out of the layout process for tight layout only by setting them manually to not be in the layout : set_in_layout(False). Thats preferable to just taking spines out for any use of get_tightbbox. If you just remove spines then savefig(bbox='tight') won't work anymore for spines that are significantly displaced from their axes.

@fredrik-1
Copy link
Contributor

Yes, thats correct - when the zoom button is active the axes resizing will stop. I think its pretty arguable whether the axes size should jump around while zooming.

I believe that it is the exact behavior that you want if you use set_tight_layout(True). The axes usually don't jump around that much that it seems strange either.

@jklymak jklymak force-pushed the fix-stop-tight-layout-collapse branch from 70e7d18 to d636914 Compare July 23, 2018 13:48
@jklymak
Copy link
Member Author

jklymak commented Jul 23, 2018

OK, this version just takes spines out of the layout if tight_layout is called. The only drawback is that they will still be taken out for savefig(bbox='tight')

@jklymak jklymak force-pushed the fix-stop-tight-layout-collapse branch from d636914 to d95d80d Compare July 23, 2018 13:50
@jklymak
Copy link
Member Author

jklymak commented Jul 23, 2018

Closing for #11754

@jklymak jklymak closed this Jul 23, 2018
@jklymak jklymak deleted the fix-stop-tight-layout-collapse branch July 23, 2018 19:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Bug in tight_layout
2 participants