Automargin pipeline

[alexcjohnson]

Our automatic margin expansion system is a mess: components generally determine their sizes - and thus the amount they need to increase the margin - only while being drawn. So in order for the new margin to take effect, the component gets drawn, which updates the margin calculation, then all of these components need to be drawn again if the new margin is different from the old one. The situation is even worse for axis automargins, since axes are drawn later in the process, changes they make to the margins result in an entire redraw of the plot, ie nearly doubling the initial plot time.

Much better would be to separate out margin calculations from component drawing; that way we can determine all sizes before we draw anything, then each component need only be drawn once. The challenge with this is that these sizes depend on text bounding boxes, so in order for this not to add its own overhead we may need to create the text elements as part of the margin calculation step, stash them somewhere hidden, and then pull them back out during the drawing step and attach them to the component. Or perhaps the two steps are 1) component creation and sizing, 2) component positioning and updating?

Some related discussion happened during #2681. See also #1988 and #2434.

[nicolaskruchten]

we can determine all sizes before we draw anything, then each component need only be drawn once

This wasn't possible the first time round because as the margins change, some components change how they draw themselves... for example as the left margin increases, the x-axis tick labels compress and then draw themselves on an angle.

[etpinard]

After an investigation, I'm realising that our "pipeline problems" are a little deeper than first expected, specifically for cartesian axes.

In brief, cartesian auto-margin push values depend on the axis range (as the axis range determines which tick labels appear on the graph and thus their size) AND cartesian axis auto-range depends on the margins (via ax._length which is used as a scale factor for padded auto-range computations). Unfortunately this can lead to infinite loops (cc #4028). Margins and axis ranges get even more intertwined when axis constraints are set.

To illustrate, consider:

Plotly.newPlot('graph', [{
  mode: 'markers',
  marker: {size: 100},
  x: [1, 200, 6000]
}], {
  width: 400, height: 400,
  yaxis: {
    visible: false,
    range: [-1, 3]
  },
  xaxis: {
    tickfont: {size: 32},
    tickangle: 'auto',
    automargin: true,
    autorange: true
  },
  margin: {l: 0, t: 0, r: 0, b: 0}
})

where the auto-range padding and auto-margin push values are exaggerated via marker.size and xaxis.tickfont.size respectively. In this simplified example, only the x-axis contributes to the auto-margin computations (e.g. there are no legend, colorbar etc) and only the x-axis is auto-ranged.

With the current pipeline, Plotly.newPlot:

• Computes an autorange value with ax._length being the graph's width (i.e. 400 in our case here).
• Draws the x-axis ticks, computes their margin push values
• As the margin push lead to a bigger margin than the input margin: {l: 0, t: 0, b: 0, r: 0}, we replot
• Computes a 2nd autorange value with ax._length = gs.w which is now smaller than 400. As the axis length in pixel space in now smaller: the auto-axis range has now a larger span than during the first iteration
• Draw news x-axis ticks. In general, the new tick labels have a different bounding box than during the first iteration. In our case, with the smaller ax._length, the x-axis labels overlap and get auto-rotated to tickangle: 90 meaning a much smaller bounding box width
• As the new (smaller) x margin push values are still bigger than margin: {l: 0, t: 0, b: 0, r: 0}, we replot again
• Now on this 3rd iteration, ax._length is larger than during the 2nd. In our case, this leads x-axis labels *not overlapping on the horizontal, big x margin push values and one more replot
• The 4rd iteration leads to vertical x-axis labels and small x margin push values.
• .... and so on until Uncaught RangeError: Maximum call stack size exceeded 💥

---

So, there are a few ways to "quickly" fix the problem. Off the top of my head:

• Keep count of the "replots" triggered by the Plots.doAutoMargin, bail out after say the 2nd replot
  • but this may lead to inconsistency between newPlot and some relayout calls
• Do not go back and forth between computed "auto" tick angle during the same Plots.doAutoMargin cycle
  • This would fix the above example, but I suspect it's possible to trigger an infinite even with a fixed angle
• Do not compute the auto-margins from scratch during a replot
  • Here too, I'm not convinced this would make us avoid all potential infinite loops

All in all, I can wait to get rid of the replot calls inside Plots.doAutoMargin.

[nicolaskruchten]

The approach I used in my original *axis.automargin PR is to avoid backtracking: basically the margins only ever get bigger, even if it looks like they could shrink.