zoom/pan stack bug in 2.1.0

[DeadParrot]

For plots after the first one created on a canvas the zoom/pan stacks can have _pos == -1 and, due to a change in 2.1.0 (fb83117), this position offset error causes unzoom and unpan back operations to think they have reached the top of the stack one step before they have.

The code change that causes this was the removal of these lines from press_pan and press_zoom:

if self._views.empty():
    self.push_current()

which reset the Stack _pos to 0. Restoring this code corrects the issue but may not be the desired fix given the intended refactoring.

Matplotlib version

• Operating system: Windows
• Matplotlib version: 2.1.0
• Matplotlib backend (print(matplotlib.get_backend())): Qt4Agg
• Python version: 2.7.14
• Other libraries: latest NumPy, PySide, ...

[tacaswell]

attn @anntzer

This was changed in fb83117

The call back that was added for draw_event should have made it so that those conditionals should never be true iirc....

[anntzer]

I'm looking at it, but it's not obvious why the previous code (before that patch) would even work for dynamically added axes. @DeadParrot Can you describe the sequence of actions / code that allows reproducing the issue (and used to work in 2.0)? Thanks.

[DeadParrot]

Sure, @anntzer. We have a QWidget that has a matplotlib canvas that we reuse for plots of different data sets the user selects. We could but we don't discard the canvas between plots. The _pos is -1 on entry to the first press_pan or press_zoom call for each plot after the first plot. If I can replicate this in a small example I'll post that here.

[tacaswell]

Do you have a toolbar installed in your widget?

[DeadParrot]

Yes. We have a toolbar and we also wired up right-click to call back().

[anntzer]

OK, so I think the correct fix is to keep define_home hooked to draw_event and have it check whether the axes set has changed or not. If it has, push the state.

[2sn]

I have the same issue in standard plots using TkAgg/Python 3.6.3. The original state is lost, the home button only gets me back to the first zoom/pan action. Even for vanilla plots of the kind

f = plt.figure()
ax = f.add_subplot()

(nothing else)

The you move a few times, then press the home button - but don't return to the original zoom/viewport.

This seems to be particularly reproducible in ipython, less so under plain python3.

[2sn]

I seem to still see that issue on the current master branch but #9359 seems to fix it. Seems rather important to fix/merge.

[2sn]

Is there a way to manually add the "home" zoom/pan level to the stack until this is fixed?

[tacaswell]

Fixed by #9359

[DeadParrot]

@tacaswell @anntzer Sadly, this seems to be broken again in 2.2.0. I can open a new issue for this if preferred.

[2sn]

bummer ...

…

On 07/03/18 12:58, Stuart Mentzer wrote: @tacaswell <https://github.com/tacaswell> @anntzer <https://github.com/anntzer> Sadly, this seems to be broken again in 2.2.0. I can open a new issue for this if preferred. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#9358 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABNtFgcWGeaK9mV080GstSVj8kQOiIMJks5tbz7IgaJpZM4P02ND>.

[2sn]

@DeadParrot I have to admit, I cannot reproduce/confirm the existence of this issue in 2.2.0. Could you please provide an example?

[anntzer]

Can't reproduce it either...

[DeadParrot]

Sorry for the delay. I tried to build small examples showing the issue but since these worked I looked into our code and it looks like our toolbar class overrode the update method in a way that worked before but didn't in 2.2.0. I was able to resolve our issue by restoring the inherited update behavior and I'm hoping this doesn't again break things for our users on older matplotlib versions.

Upshot is that there was definitely an internal change in 2.2.0 that tripped us up but I can't conclude that it is a bug so let's leave this closed for now. Thanks!