FazBrowse GitHub Viewer | Trending |
URL:
| Home
Tools: [Download Repo ZIP]   [Original HTTPS Page]

zooming problem on figures with shared axes · Issue #2790 · matplotlib/matplotlib · GitHub

Repository navigation

zooming problem on figures with shared axes #2790

Closed

Description

Hi!

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

Activity

  1. added this to the v1.4.x milestone on Mar 20, 2014
  2. tacaswell commented on Mar 20, 2014

    Member

    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).

  3. WeatherGod commented on Mar 20, 2014

    Member

    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.

  4. tacaswell commented on Mar 20, 2014

    Member

    This does not involve closing windows, just resizing them.

  5. WeatherGod commented on Mar 20, 2014

    Member

    Except for the part where it does: "Interestingly if I close the figures my
    shell still keeps on doing stuff backstage"

  6. tacaswell commented on Mar 20, 2014

    Member

    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.

  7. modified the milestones: v1.4.x, on Feb 7, 2015
  8. tacaswell commented on Jul 17, 2015

    Member

    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').

  9. efiring commented on Nov 12, 2015

    Member

    @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.

  10. mdboom commented on Nov 12, 2015

    Member

    @efiring: Should we reopen this, then?

  11. 4 remaining items

  12. efiring commented on May 22, 2016

    Member

    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.

  13. modified the milestones: , v1.5.0 on Aug 1, 2016
  14. modified the milestones: , on May 3, 2017
  15. added a commit that references this issue on Jun 4, 2017
    bdd06dd
  16. modified the milestones: , on Oct 9, 2017
  17. jklymak commented on Aug 17, 2018

    Member

    I don't see that this is a problem anymore on master. I'm guessing recent work has fixed this...

  18. removed this from the future releases milestone on Oct 6, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions


    Back | FazBrowse Home | New Git URL