GeezerVison is showing github.com — zooming problem on figures with shared axes · Issue #2790 · matplotlib/matplotlib
zooming problem on figures with shared axes #2790DescriptionHi!
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)
thanks in advance!
JF Activitytacaswell 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:
import matplotlib.pyplot as plt
fig0 = plt.figure()
a0 = fig0.add_subplot(121)
a0.set_adjustable('box-forced')
a0.imshow(p.rand(100, 100))
a1 = fig0.add_subplot(122, sharex=a0, sharey=a0)
a1.set_adjustable('box-forced')
a1.imshow(p.rand(100, 100)**2)
fig1 = plt.figure()
a2 = fig1.add_subplot(121, sharex=a0, sharey=a0)
a2.set_adjustable('box-forced')
a2.imshow(p.rand(100, 100)**3)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 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. modified the milestones: This milestone has been deleted, This milestone has been deleted on May 3, 2017added a commit that references this issue on Jun 4, 2017This issue will close once commit bdd06dd is merged into the 'main' branch.bdd06dd modified the milestones: This milestone has been deleted, This milestone has been deleted on Oct 9, 2017jklymak 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...
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|