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
matplotlib-devel List Signup and Options
--
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.