I am trying to use axes shared across different figures and run into a funny effect when I resize one of the windows.
If I do:
import pylab as p
a0 = p.subplot(121)
p.imshow(p.rand(100,100))
a1 = p.subplot(122,sharex=a0,sharey=a0)
p.imshow(p.rand(100,100)**2)
p.figure()
a2 = p.subplot(121,sharex=a0,sharey=a0)
p.imshow(p.rand(100,100)**3)
zooming into one of the axes does as expected: the other two follow.
However, when I resize one of the windows, all three axes zoom out completely (and not in one jump, it looks like seeing the image would be slowly falling away...)
Interestingly if I close the figures my shell still keeps on doing stuff backstage: my cpu is 100% busy. I tried this both under Ipython and a normal python shell.
Under Ipython a ctrl-C leads to the following traceback.
Original exception was:
Traceback (most recent call last):
File "/usr/local/lib/python2.7/dist-packages/matplotlib-1.3.1-py2.7-linux-x86_64.egg/matplotlib/backends/backend_gtk.py", line 435, in expose_event
self._render_figure(self._pixmap, w, h)
File "/usr/local/lib/python2.7/dist-packages/matplotlib-1.3.1-py2.7-linux-x86_64.egg/matplotlib/backends/backend_gtkagg.py", line 84, in _render_figure
FigureCanvasAgg.draw(self)
File "/usr/local/lib/python2.7/dist-packages/matplotlib-1.3.1-py2.7-linux-x86_64.egg/matplotlib/backends/backend_agg.py", line 451, in draw
self.figure.draw(self.renderer)
File "/usr/local/lib/python2.7/dist-packages/matplotlib-1.3.1-py2.7-linux-x86_64.egg/matplotlib/artist.py", line 55, in draw_wrapper
draw(artist, renderer, *args, **kwargs)
File "/usr/local/lib/python2.7/dist-packages/matplotlib-1.3.1-py2.7-linux-x86_64.egg/matplotlib/figure.py", line 1034, in draw
func(*args)
File "/usr/local/lib/python2.7/dist-packages/matplotlib-1.3.1-py2.7-linux-x86_64.egg/matplotlib/artist.py", line 55, in draw_wrapper
draw(artist, renderer, *args, **kwargs)
File "/usr/local/lib/python2.7/dist-packages/matplotlib-1.3.1-py2.7-linux-x86_64.egg/matplotlib/axes.py", line 2086, in draw
a.draw(renderer)
File "/usr/local/lib/python2.7/dist-packages/matplotlib-1.3.1-py2.7-linux-x86_64.egg/matplotlib/artist.py", line 55, in draw_wrapper
draw(artist, renderer, *args, **kwargs)
File "/usr/local/lib/python2.7/dist-packages/matplotlib-1.3.1-py2.7-linux-x86_64.egg/matplotlib/axis.py", line 1093, in draw
renderer)
File "/usr/local/lib/python2.7/dist-packages/matplotlib-1.3.1-py2.7-linux-x86_64.egg/matplotlib/axis.py", line 1042, in _get_tick_bboxes
extent = tick.label1.get_window_extent(renderer)
File "/usr/local/lib/python2.7/dist-packages/matplotlib-1.3.1-py2.7-linux-x86_64.egg/matplotlib/text.py", line 757, in get_window_extent
bbox = bbox.translated(x, y)
Perhaps there is a subtle assumption that shared axes must be on the same
figure. Aren't callbacks tied to the figure object? With the weakrefs in
the callback architecture, I would wonder if closing out figures that have
shared axes between them caused some sort of "detached circular reference"
issue preventing the axes and callbacks from being garbage collected.
@tacaswell, your example above (just the first figure part) works only when the image domains are identical; for example, if you clear the second axes and then call imshow with np.random.rand(20,20), the first image will show only its 20x20 subarray.
Even though we now have an example of sharing in different figures, the bug remains as originally described in this issue, complete with 100% CPU after closing the windows.
Regardless of how the endless loop is arising, the underlying problem is a fundamental conflict between locking together the x and y limits and the aspect ratio between axes in two figures when the figure aspect ratio is not identical. This is just one of the examples of where aspect ratio handling and sharing runs into the problem of over-specification, which is the reason I never liked the box_forced option--it only works under restrictive conditions.
Activity
tacaswell commented on Mar 20, 2014
That is a fun bug and can confirm it on master.
This so probably something subtle deep in the callback code so I am tagging this as 1.4.x (instead of 1.4.0).
WeatherGod commented on Mar 20, 2014
Perhaps there is a subtle assumption that shared axes must be on the same
figure. Aren't callbacks tied to the figure object? With the weakrefs in
the callback architecture, I would wonder if closing out figures that have
shared axes between them caused some sort of "detached circular reference"
issue preventing the axes and callbacks from being garbage collected.
tacaswell commented on Mar 20, 2014
This does not involve closing windows, just resizing them.
WeatherGod commented on Mar 20, 2014
Except for the part where it does: "Interestingly if I close the figures my
shell still keeps on doing stuff backstage"
tacaswell commented on Mar 20, 2014
Fair enough, but that is well after the bug has been triggered, I would classify that as a symptom rather than a cause.
After re-sizing zooming also does not work correctly.
tacaswell commented on Jul 17, 2015
This can be solved the same way as #1325
The following works as expected:
The key is the ax.set_adjustable('box-forced').
efiring commented on Nov 12, 2015
@tacaswell, your example above (just the first figure part) works only when the image domains are identical; for example, if you clear the second axes and then call imshow with np.random.rand(20,20), the first image will show only its 20x20 subarray.
mdboom commented on Nov 12, 2015
@efiring: Should we reopen this, then?
4 remaining items
efiring commented on May 22, 2016
Even though we now have an example of sharing in different figures, the bug remains as originally described in this issue, complete with 100% CPU after closing the windows.
Regardless of how the endless loop is arising, the underlying problem is a fundamental conflict between locking together the x and y limits and the aspect ratio between axes in two figures when the figure aspect ratio is not identical. This is just one of the examples of where aspect ratio handling and sharing runs into the problem of over-specification, which is the reason I never liked the box_forced option--it only works under restrictive conditions.
BUG: raise ValueError if sharex, sharey point to a different figure
jklymak commented on Aug 17, 2018
I don't see that this is a problem anymore on master. I'm guessing recent work has fixed this...