Repository navigation
transiently linked interactivity of unshared pair of axes generated with make_axes_locatable #12613
Description
Bug report
Bug summary
In panning mode of the figure window, all vertical and the common horizontal axes are affected by the very first drag of the mouse, irrespective of the subplot addressed by the mouse. After that, which of the vertical axes are affected depends on the addressed subplot (almost as expected).
Code for reproduction
import matplotlib.pyplot as plt
from mpl_toolkits.axes_grid1 import make_axes_locatable
fig, ax1 = plt.subplots()
ax2 = ax1.twinx()
ax_top = make_axes_locatable(ax1).append_axes('top', size=1.2, pad=0., sharex=ax1)
ax_top.xaxis.set_tick_params(labelbottom=False)
ax1.plot([0, 1, 2], [0, 1, 0])
ax2.plot([0, 1, 2], [10, 10, 11])
ax_top.plot([0, 1, 2], [90, 91, 90])
#ax_top.set_navigate(False)
plt.show()Actual outcome
(A bug that may be related: The right axis extends (with tick marks and tick labels) over the full height including the top subplot, although the right axis is autoscaled so that the trace assigned to it fits into the lower subplot as I expected.)
- On the very first mouse gesture ... (see Bug sumary).
- On subsequent mouse gestures in the top subplot, still all axes are affected.
- On subsequent mouse gestures in the lower subplot, only the two vertical axes of that subplot, left and right, are affected (besides the common x axis).
Expected outcome
- The first drag should not behave differently.
- A drag in the top subplot should only affect the axes of that subplot.
- Expected as observed.
If it is not needed to interactively change the top left axis, a workaround would be ax_top.set_navigate(False). This works also for the very first drag.
Matplotlib version
- Operating system: Windows 7
- Matplotlib version: 3.0.0
- Matplotlib backend: TkAgg
- Python version: 3.6.1
Installed using pip
Activity
ImportanceOfBeingErnest commented on Oct 24, 2018
It may kind of be expected that the matplotlib .twinx() isn't compatible with the mpl_toolkits' AxesDivider.
So the code should probably rather use the mpl_toolkits.axes_grid1.host_subplot to create the subplot.
import matplotlib.pyplot as plt from mpl_toolkits.axes_grid1 import make_axes_locatable, host_subplot ax1 = host_subplot(111) ax_top = make_axes_locatable(ax1).append_axes('top', size=.5, pad=0.2, sharex=ax1) ax2 = ax1.twinx() ax1.plot([0, 1, 2], [0, 1, 0]) ax2.plot([0, 1, 2], [10, 10, 11]) ax_top.plot([0, 1, 2], [90, 91, 90]) plt.show()Now the problem is that this code is broken. It would work in matplotlib 2.1, but the introduction of the constrained layout killed it - bisects to #9082 (attn. @jklymak)
jklymak commented on Oct 24, 2018
I am at a loss as to how this was affected by constrained layout if constrained layout is not in your Matplotlibrc or invoked in your code.
ImportanceOfBeingErnest commented on Oct 24, 2018
That PR changes 37 files, so it's sure not easy to find out what exactly went wrong there. I noticed the change of set_position/_set_position though, so maybe something is now calling the wrong one of those?
jklymak commented on Oct 24, 2018
Maybe? But I can't reproduce this on master using Qt5Agg Are you sure your rcParams are set to default?
Like, really, constrained_layout should do nothing on these axes...
If you want to see if CL is called, put a (EDIT:) print statement the beginning of _constrained_layout.py/do_constrained_layout(); if I do this its never called, and I don't get any resizing...
jklymak commented on Oct 24, 2018
OK, I see, I can reproduce on 3.0.0.
@ImportanceOfBeingErnest your issue is the same as the other axesgrid issues, closed by #12363 and fixed in master and 3.0.1.
Not sure if this closes the issue...
ImportanceOfBeingErnest commented on Oct 24, 2018
Oh sorry, I should really fetch upstream every morning or so. Apparently #12363 then fixed something which got introduced in 2.2 and something which got introduced in 3.0 at the same time.
I would say yes, this closes the issue. Because I don't think we want to start supporting axes_grid1 in combination with twinx from the main library. axes_grid1's host_subplot has its own twinx, which should be used instead.
@Rainald62 What this means for you is that you would need to wait till 3.0.1 is out (in a couple of days, max 2 weeks) and then use the proposed code from above. Alternatively, you may always decide to not use the axis_grid1 toolkit at all and work with usual subplots from the main library.
jklymak commented on Oct 24, 2018
It was confusing. I'm surprised it bisected to #9082, but I think you are right - the set_position stuff was broken. #12363 did add a couple of tests, so hopefully this doesn't break for axesgrid again (while I think axesgrid should be moved into the main library as much as possible, I'm not actively trying to break it!)
ImportanceOfBeingErnest commented on Oct 24, 2018
So the reason people use axes_grid1 with its axesdivider is that is allows to keep the geometry of axes in sync, i.e. having one fixed-aspect axes and another auto-aspect axes next to/underneath each other, they want to have them both the same height/width. There currently seems no easy way to do this with subplots from the main library (solutions are currently to calculate and set a fixed aspect to the other subplot as well, to mess with the subplot params to box up the subplots, or to set the position manually - all of which would require a callback on resize/zoom/pan/limitchange events.) Most prominently this affects colorbars for images, but of course equally other subplot combinations.
Rainald62 commented on Oct 30, 2018
Many thanks for the help. I updated to 3.0.1, changed to host_subplot, and learned that this function does not return fig, which I need in a call to FuncAnimation. A preceeding fig = plt.figure() did it.