Fix for removing erratic jittering during scrolling/zooming

[Eroica]

This PR addresses two sources of erratic zooming behavior.

The first issue is documented here: #7494

Especially in charts that use auto margins, the plot area updates "erratically," i.e. with visual jumps. This issue can be solved by correctly setting the _replotting flag in zoomWheel, which causes plots.autoMargin (plots.js) to skip its calculation.

Before this PR, zoomWheel's setTimeout callback just set this flag to false without setting it to true before.

---

The 2nd issue reveals itself when multiple subplots are present: When zooming while moving the cursor to a different subplot, multiple subplots fire their updateSubplots with slightly different viewboxes which leads to visual jumping. The issue appears more frequently on data-intensive charts.

Note that this is very hard to replicate with a trackpad. It's best to test this with a free-spinning mouse wheel.

second_issue.json

(Start zooming on one subplot, and move the mouse onto another subplot while continuing zooming.)

second_issue.mp4

[alexcjohnson]

IIRC this id is just the two axis ids concatenated, like x2y2, yes? What would happen if you put two plot divs next to each other, each with just one x and one y axis, and you do the same kind of move but now from one div to the other? Where I'm coming from is typically we attach state variables like this (and like _replotting) to the div (gd) rather than having a single one for the whole library.

[Eroica]

You are right, plotinfo.id could come up multiple times over different plots. Is it OK if I store _currentScrollingSubplot in gd by setting it directly like here: a9f1218

(Also added the new attribute to purge in plots.js)

[alexcjohnson]

Works for me!

[Eroica]

Reverting 244ebaf because it behaves badly with manual relayout events (e.g. to update axes titles). We are currently looking into another approach for zoomWheel that will work similar to plotDrag.

[emilykl]

@Eroica I'm converting this to draft for the moment, please mark as "Ready for review" as soon as you're ready for someone to take a look. Thanks for your work on this 🙂

[Eroica]

These "typical" erratic jumps often appeared when controlling Plotly via external libraries, e.g. the Python API. For example, we discussed a setup like this (using Panel):

def on_viewport_change(event):
    ...
    new_images = build_layout_images(x0, x1, y0, y1)
    fig.layout.images = new_images
    plotly_pane.object = fig


plotly_pane.param.watch(on_viewport_change, 'viewport')

Would lead to react (in plot_api.js) being called twice on the JavaScript side, and messing up the viewport. Crucially, if the original fig object is constructed with range parameters, then these are always provided to the react callback even though the user's movement could update them inbetween.

While this could be because of an edge case in Plotly's react (and I laid out a possible workaround in this branch: https://github.com/Eroica/plotly.js/tree/react-fixes), it's not strictly necessary to update Plotly's JavaScript side to fix the issue.

Skipping the fig.layout.images = new_images part in the callback or constructing the figure object without ranges first (only updating them later) also avoids the issue altogether.