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

3D axes are going to get pretty distorted with xy scaling like this, could you check for a zaxis and either extend the zooming to that or block it altogether?

Only rectilinear Axes are affected at this point.

@QuLogic I‘m fine either way. You can take over this PR or add the transformation as a separate PR afterwards.

I had a quick play, and on linear scales this is super neat!

On a double log scale (or a single too), it's very easy to hit these warnings when zooming:

/Users/dstansby/software/mpl/matplotlib/test.py:9:UserWarning:Attempttosetnon-positivexlimonalog-scaledaxiswillbeignored.plt.show()/Users/dstansby/software/mpl/matplotlib/test.py:9:UserWarning:Attempttosetnon-positiveylimonalog-scaledaxiswillbeignored.plt.show()

which probably shouldn't be happening. With#30405 (comment) applied though, this isn't an issue, and the zooming looks more natural to me because the data points stay rigid instead of stretching about. So I think it makes sense to apply#30405 (comment) before this is merged.

I've included push#30405 (comment). That's indeed much better for nonlinear scales. Thanks@QuLogic! 🚀

I've additionally increased the zoom step from 5% to 10%. With 5% it felt I had to scroll a lot to zoom into any part of the plot. With 10% there are still 7 scroll steps to get a factor of ~2. That's definitively enough granularity. Note, I also checked outbokeh and they have a ~20% step, meaning 3 steps for a factor ~2.

Question: During testing I was somewhat annoyed that I always had to select a tool before the scroll wheel had any effect - or rather I scrolled and was annoyed that nothing happened. Maybe that's a biased use case, but I'm wondering whether we could generally activate scroll-to-zoom independent of the tool state. - The argument not to do this was to ensure the plot was not modified unintentionally. But OTOH how often do you scroll unintentionally? Also, we have "undo" and "reset to original view" so that one could recover if that really happens.

I propose tying it to the tool for 3.11 and making it always-on in 3.12 just in case there is some pathological stress-cases we are not thinking of yet.

Having it opt-in for a while will be enough time for people to find and report those cases.

The other reason not to make it alwasy on by default (at least not without warning) is that users may have hooked their own things up to scroll and we do not want to conflict with them on day 0.

Hopefully fixed docs through a rebase.

I would really not want to have scroll by default for two reasons: 1) I indeed have scroll_event hooked up to other stuff quite often, and 2) on a mac magicmouse it is indeed quite easy to scroll accidentally.

The other reason not to make it alwasy on by default (at least not without warning) is that users may have hooked their own things up to scroll and we do not want to conflict with them on day 0.

I'll note that on my Mac, none of the graphics packages I use automatically have scroll attached to zoom, though some of them use a modifier key: Adobe products option-scroll to zoom in or out and Inkscape uses Ctrl-scroll. Scroll pans in most packages I use. However I use a Magic Mouse, and I don't have access to a scroll wheel, so maybe my understanding of what is proposed here is incorrect. Are there graphics packages that use scroll-to-zoom by default?

Finding the right operation for zoom is not trivial.

• Most graphics tools use wheel for vertical scrolling and Ctrl+Wheel for zoom. Not sure why they do it; either because they find it correct, it's what others do or because of a technical reason - note that they all operate on finite canvases and have widgets with scroll bars attached - it could be that with scoll bars wheel=vertical scroll is the easy or right thing.
• bokeh does nothing by default (i.e. the wheel scrolls the embedding web page). They have a dedicated "Wheel zoom" button. If activated, they zoom on wheel only. This button makes sense since bokeh is typically embedded in webpages and they don't want to steal the wheel event from the page unless explicitly desired by the user. But if they take over, they don't use any further modifiers.
• As a full-window application, Google Maps does not use modifiers either.

What can we learn from them?

In our context, the canvas has no scollbars and there is no outer context which needs to be accounted for, so there is no particular other use for a wheel-only event (I would refrain from assigning it to vertical scroll). So wheel-only could either be zoom or a noop.
Conversely, i believe there are to valid approaches which action should zoom:

• Use wheel-only on the basis that nothing else needs it and it's easier than using an additional modifier (this is the Google Maps argument)
• Use Ctrl+Wheel on the basis that most other tools use Ctrl+Wheel (for whatever reason)

After thinking a bit more, I suggest to go with this approach: Use "Ctrl+Wheel" but keep it always on, i.e. independent of any tool status.

Rationale:

• Avoid ambiguity: Ctrl+Wheel is overwhelmingly associated with zooming. - If somebody does Ctrl+Wheel they most likely want to zoom.
• Be defensive: We could always later make Wheel-only also zoom if we come to the conclusion that makes sense.
• Usability: Ctrl+Wheel is harder to trigger accientally. Therefore we can afford to make it always-on.

I will change to this behavior later. Please speak up if you have any concerns with this approach.

I've also fine-tuned the zoom factor to 0.85, which means approximately 5 zoom steps for a factor 2. I felt this is a good trade of between speed of zooming and detailed control. The mouse wheel is not intended for precision zoomin (better use the zoom box instead). Therefore we can tune a bit more towards speed.

Re-ran the two failures, expect one of them to pass (failure to install system deps from brew) and one to fail again (gtk has started warning on import).

Merging based on the two formal approvals and the thumbs-ups to the changed behavior#30405 (comment)