shared axis zoom bug

pan/zoom appears to be broken in the sharex axis demo. If you do a
zoom to rect on ax2 or ax3 in
examples/pylab_examples/shared_axis_demo.py the event seems to be
swallowed, though a zoom in ax1 is respected.

I know Eric was recently working on autoscale support for sharex axes

  r6315 | efiring | 2008-10-23 19:08:58 -0500 (Thu, 23 Oct 2008) | 2 lines

  Support autoscaling with shared axes

And perhaps the current bug is related to the problem Michael
wrote about earlier in the thread: "shared axes" bug in matplotlib
0.98

  Back when the 0.98 transformations were being written, John and I
  had a long discussion about whether data limits should be Bbox-like
  or pair-of-intervals-like, and we ultimately decided to leave things
  as-is to avoid creating too much newness at once. IMHO, however,
  the real problem is that the shared axes mechanism doesn't know
  whether the limits are changing because of autoscaling (in which
  case the limits should be unioned together), or panning/zooming, in
  which case the limits need to be replaced. The second problem is
  probably necessary to fix whether we use Bboxes or not.

JDH

The problem appears to be in the backend_bases
NavigationToolbar2.release_zoom method. I have updated svn r6447 with

            # JDH: I don't know why this is here but I expect to be
            # able to zoomo on any axis that is shared. This was
            # breaking zoom-to-rect on shared_axis_demo if the zoom
            # happened in ax2 or ax3 so i am replacing the continue
            # with a pass until this is sorted out
            if a._sharex or a._sharey:
                #continue
                pass

If anyone knows why the continue was/should be there, speak up!

JDH

···

On Tue, Nov 25, 2008 at 12:16 PM, John Hunter <jdh2358@...149...> wrote:

pan/zoom appears to be broken in the sharex axis demo. If you do a
zoom to rect on ax2 or ax3 in
examples/pylab_examples/shared_axis_demo.py the event seems to be
swallowed, though a zoom in ax1 is respected.

OK, I think I see where this came in. I did an svnmerge the other day
from the branch, and merged in Michael's change:

  r6365 | mdboom | 2008-11-05 09:15:28 -0600 (Wed, 05 Nov 2008) | 1 line

  Fix bug in zoom rectangle with twin axes

Michael, perhaps you can comment on this bugfix on the branch, and
whether this change or something like it should be in the trunk? I
see the trunk has some additional logic that the branch does not have:

            # detect twinx,y axes and avoid double zooming
            twinx, twiny = False, False
            if last_a:
                for la in last_a:
                    if a.get_shared_x_axes().joined(a,la): twinx=True
                    if a.get_shared_y_axes().joined(a,la): twiny=True

JDH

···

On Tue, Nov 25, 2008 at 12:28 PM, John Hunter <jdh2358@...149...> wrote:

On Tue, Nov 25, 2008 at 12:16 PM, John Hunter <jdh2358@...149...> wrote:

pan/zoom appears to be broken in the sharex axis demo. If you do a
zoom to rect on ax2 or ax3 in
examples/pylab_examples/shared_axis_demo.py the event seems to be
swallowed, though a zoom in ax1 is respected.

The problem appears to be in the backend_bases
NavigationToolbar2.release_zoom method. I have updated svn r6447 with

           # JDH: I don't know why this is here but I expect to be
           # able to zoomo on any axis that is shared. This was
           # breaking zoom-to-rect on shared_axis_demo if the zoom
           # happened in ax2 or ax3 so i am replacing the continue
           # with a pass until this is sorted out
           if a._sharex or a._sharey:
               #continue
               pass

If anyone knows why the continue was/should be there, speak up!

The change doesn't apply to the trunk. The shared axes logic is completely different now. Whereas before there was a unidirectional link from one axes to another, and a concept of "master" and "slave" axes, the new version avoids that complication by using the "Grouper" class.

The bug fix was required on the branch because the zoom rectangle was getting "doubly applied", once for each axis which caused (in effect) for the zoom to go too far. The fix was simply to ignore one of the axes, in this case the "master" axes.

The trunk has effectively the same fix already in that additional code you point out. Its purpose is to make sure the zoom happens only once for each grouping. It could probably be done better, but it does work.

So the software engineering lesson here, is I should have remembered to merge my own change on the branch -- I would have known right away it didn't apply. (Actually, that's probably why I didn't merge it, but of course, you still have to let SVN know you don't want to merge the change somehow...)

Mike

John Hunter wrote:

···

On Tue, Nov 25, 2008 at 12:28 PM, John Hunter <jdh2358@...149...> wrote:
  

On Tue, Nov 25, 2008 at 12:16 PM, John Hunter <jdh2358@...149...> wrote:
    

pan/zoom appears to be broken in the sharex axis demo. If you do a
zoom to rect on ax2 or ax3 in
examples/pylab_examples/shared_axis_demo.py the event seems to be
swallowed, though a zoom in ax1 is respected.
      

The problem appears to be in the backend_bases
NavigationToolbar2.release_zoom method. I have updated svn r6447 with

           # JDH: I don't know why this is here but I expect to be
           # able to zoomo on any axis that is shared. This was
           # breaking zoom-to-rect on shared_axis_demo if the zoom
           # happened in ax2 or ax3 so i am replacing the continue
           # with a pass until this is sorted out
           if a._sharex or a._sharey:
               #continue
               pass

If anyone knows why the continue was/should be there, speak up!
    
OK, I think I see where this came in. I did an svnmerge the other day
from the branch, and merged in Michael's change:

  r6365 | mdboom | 2008-11-05 09:15:28 -0600 (Wed, 05 Nov 2008) | 1 line

  Fix bug in zoom rectangle with twin axes

Michael, perhaps you can comment on this bugfix on the branch, and
whether this change or something like it should be in the trunk? I
see the trunk has some additional logic that the branch does not have:

            # detect twinx,y axes and avoid double zooming
            twinx, twiny = False, False
            if last_a:
                for la in last_a:
                    if a.get_shared_x_axes().joined(a,la): twinx=True
                    if a.get_shared_y_axes().joined(a,la): twiny=True

JDH

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
  
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

OK, thanks for the explanation. I've purged the invalid merge from the trunk.

JDH

···

On Tue, Nov 25, 2008 at 1:31 PM, Michael Droettboom <mdroe@...31...> wrote:

The trunk has effectively the same fix already in that additional code you
point out. Its purpose is to make sure the zoom happens only once for each
grouping. It could probably be done better, but it does work.