An optional feature I really like that I have in mpl-pan-zoom is to autocenter on the plot if you zoom out by a lot. This is what programs like gimp do, it makes it so you don't completely lose track of where the data extents are: https://github.com/mpl-extensions/mpl-pan-zoom/blob/158c68bc3ba5bab785b0a7cb4719774af0a632ac/mpl_pan_zoom/_zoom.py#L76

A second note is that for the web/notebook backends this basically has to capture scrolls if you want it to work properly. Would it be possible to add support for ipympl by adding something like this: https://github.com/mpl-extensions/mpl-pan-zoom/blob/158c68bc3ba5bab785b0a7cb4719774af0a632ac/mpl_pan_zoom/_zoom.py#L32-L33 otherwise this will result in behavior like this: matplotlib/ipympl#222

A final thought. I haven't tested this but it may be important to test this on non-euclidean projections. For example see this issue: mpl-extensions/mpl-pan-zoom#10

A final thought. I haven't tested this but it may be important to test this on non-euclidean projections. For example see this issue: mpl-extensions/mpl-pan-zoom#10

Indeed. In non-rectilinear cases it is not correct to just reduce the data limits. I've limited this functionality to rectilinear Axes for now. I suspect, every projection needs its own recipe. - For example polar plots should not change the theta limits at all.

I think this doesn't support scales other than linear for now (well, I guess it depends on the exact behavior one expects); I suspect the proper behavior would be to perform the zooming in pixel coordinates rather than in data coordinates?

re: view history; I guess a "relatively" simple fix would be to record whether the last history entry pushed into the stack was from a scroll-zoom, and if so and if the current entry being pushed is also a scroll-zoom (optionally: a scroll zoom from the same point), then pop the last entry before pushing the new one?

I have no time to work on this further in the near future.

I believe the current state is good enough for a start, given that a vast of majority of plots are rectilinear Axes with linear scales:

• limiting to rectilinear Axes prevents really awkward behavior.
• zooming on nonlinear scales may not be ideal, but is bearable.
• batching zoom in the history would be nice but is not essential

I propose to merge the PR as. Improvements by others are welcome but could also be done in follow-up PRs.

I propose to merge the PR as. Improvements by others are welcome but could also be done in follow-up PRs.

A second note is that for the web/notebook backends this basically has to capture scrolls if you want it to work properly. Would it be possible to add support for ipympl by adding something like this:

If this is merged I can commit to figuring what, if any, follow ups are needed here and/or in ipympl to make this feature work for webbackends

This PR adds a good and extremely useful thing, and feels to me to be standard behavior among plotting libraries now.

I wrote this to try and handle non-linear scales:

diff --git a/lib/matplotlib/backend_bases.py b/lib/matplotlib/backend_bases.py
index 815c61a0ee..10634d68a1 100644
--- a/lib/matplotlib/backend_bases.py
+++ b/lib/matplotlib/backend_bases.py
@@ -2593,10 +2593,11 @@ def scroll_handler(event, canvas=None, toolbar=None):
 
         xmin, xmax = ax.get_xlim()
         ymin, ymax = ax.get_ylim()
+        xmin, ymin = ax.transScale.transform((xmin, ymin))
+        xmax, ymax = ax.transScale.transform((xmax, ymax))
 
-        # mouse position in data coordinates
-        x = event.xdata
-        y = event.ydata
+        # mouse position in scaled (e.g., log) data coordinates
+        x, y = ax.transScale.transform((event.xdata, event.ydata))
 
         scale_factor = 1.0 - 0.05 * event.step
         new_xmin = x - (x - xmin) * scale_factor
@@ -2604,6 +2605,10 @@ def scroll_handler(event, canvas=None, toolbar=None):
         new_ymin = y - (y - ymin) * scale_factor
         new_ymax = y + (ymax - y) * scale_factor
 
+        inv_scale = ax.transScale.inverted()
+        new_xmin, new_ymin = inv_scale.transform((new_xmin, new_ymin))
+        new_xmax, new_ymax = inv_scale.transform((new_xmax, new_ymax))
+
         ax.set_xlim(new_xmin, new_xmax)
         ax.set_ylim(new_ymin, new_ymax)
 

If that makes sense, should I push that here?

Looks good, but I can’t test right now. If somebody has verified that this is the „canonically expected“ behavior e.g. on a log scale, you are welcome to push to this branch.