-
-
Notifications
You must be signed in to change notification settings - Fork 7.9k
fix tight_layout bug #11737 #11739
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 tight_layout bug #11737 #11739
Conversation
7968380
to
e8b77d6
Compare
I'm not sure whats going on, but ignoring the spines in the tight_layout is probably not a good solution. I'll look into it later. |
I wounder if it is a similar issue as #10989? The plot actually looks ok again if Ignoring the spines are probably not a good idea but the tightbboxes for the spines are not correct when calculated in |
Sorry on a phone right now but I am pretty certain I addressed the spine issue in a recent PR. But maybe just for constrained layout and not tight layout? Look at my recent closed PRs. |
OK, see #11627. This is the same problem, caused by putting all child artists (including the spines) in the tight bbox calculation (#10682). The problem with spines under zoom is that they don't get their transform updated in time for the tight_bbox calculation. That is the fundamental problem. The issue with your fix is that if the spine is displaced from the axes position it will not be included in the tight_bbox and the subplot spacing won't be adequately large enough. So, this bug all makes sense. I'm not sure what the fix for the spines not having the correct transform is, but that'd be the right thing to do. The other thing we did for |
lib/matplotlib/axes/_base.py
Outdated
if bbox is not None and (bbox.width != 0 or bbox.height != 0): | ||
bb.append(bbox) | ||
if not isinstance(a, mspines.Spine): | ||
bbox = a.get_tightbbox(renderer) |
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.
Blocking on this as I don't think this is a good solution.
e8b77d6
to
3dbc142
Compare
I updated my fix to just be used when This is mostly a hack but the behavior is probably similar to the behavior in 2.2.2 so it shouldn't break peoples working process. I rather want this behavior than the behavior in #11742 |
3dbc142
to
23420a4
Compare
I changed the order in The behavior is quite good and what I would expect in most cases but the tight_layout calculation is sometimes still slightly incorrect. |
0e4f2b8
to
09418e2
Compare
This won't position the axes properly until the second draw... |
I see now that something doesn't work. It seems to work ok with one subplot but not with several. But the thing I am after is that I think that |
OK, #11754 fixes the root of the problem, I hope. |
I believe that the issue in #11737 where some Spines that had a bounding box outside of the figure. This pr seems to solve the bug I found but I don't know enough about the details about the code to know if it is a good solution or any real solution at all.