Although I think that this is really how it should be, the question is if we can just enforce it or if there should be a deprecation path? Better ping in@timhoffm directly...

This is changing intended behavior in some of the tests so some tweaking to do, but should be enough here right now to get an idea.

Talked about this in the dev call today, consensus was to make the new behavior default without deprecation, but add an rc_param to switch back to current behavior.

This is ready for review!

Note that there are a large number (57) of baseline image edits. In all cases, these are very minor - either a 1 pixel shift in some labels, or a subpixel shift in tick locations. I believe these are likely due to accumulated floating point errors as a result of several scale conversion factors that I had to add to match the baseline formatting.

Take for example axes3d_labelpad-failed-diff.png:

Which when thresholded to maximum contrast in photoshop shows some slight subpixel shifts for the tick marks:

Well, it looks like the floating point theory is likely correct, because the tests are all passing on my machine, and the different CI platforms are having different tests throw image comparison errors. What's the proper way to handle this? Loosen the image comparison tolerance? I'm not sure how to examine the test images from the different CI environments if I can't recreate the issue locally.

The ideal way is to add platform-specific margins, like:

I think one way to make it at least slightly better is to pre-compute the constants. In this way one error source is removed and the code will execute slightly faster. Always possible to use a comment to illustrate where it comes from.

Thank you for the thorough review@oscargus!

To give some context for where these constants are coming from, the original behavior when generating the view limits for 3d plots was fairly broken. There was always 1/48 of the axis range added to either side of the axis bounds when drawing the axes, however this extra "view margin" was purely visual. The calculations for the zoom level for the plot, which grid/tick lines to show, and several other spots in the code all used the non-padded axis limits for their calculation. So, when I converted the backed to use the actual axis limits everywhere, this required putting in a lot of scale factors to keep the visual appearance (23/24 = 1-2*1/48, and25/24 = 1+2*1/48).

Talking about this with@ksunden and@QuLogic we want to take this, but given this is an API change and it is the 11th hour of the 3.8 prep, we are going to hold this for 3.9 (which means it should get merged as soon we branch).

Essentially - the old padding was 1/48, and was applied 2x (to the min and max limits), so that's where the 1 ± 1/24 scaling came from.

OK, can we mention that in the comments? It currently says something like "to match mpl3.7 appearance", so it can say "to match mpl3.7 appearance that added 1/48 padding". Also feel free to put a longer explanation in the commit message.

Thanks! Rebased/squashed, and added a lot more detail to the comments on scale factors.@QuLogic do those address your concerns?

Bump on merging this now that 3.8.0 is out

@scottshambaugh Thanks!

Unclear to me why this didn't happen for this PR, but references to[xy]axis_inverted andinvert_[xy]axis in the docstrings from this PR are causing doc build failures on main now:

https://app.circleci.com/pipelines/github/matplotlib/matplotlib/26910/workflows/8053f52d-d0f9-45f0-8b9e-e759ea3c4215/jobs/78885

/home/circleci/project/lib/matplotlib/axes/_base.py:docstring of matplotlib.axes._base._AxesBase.get_xbound:20: WARNING: py:obj reference target not found: invert_xaxis/home/circleci/project/lib/matplotlib/axes/_base.py:docstring of matplotlib.axes._base._AxesBase.get_xbound:20: WARNING: py:obj reference target not found: xaxis_inverted/home/circleci/project/lib/matplotlib/axes/_base.py:docstring of matplotlib.axes._base._AxesBase.get_ybound:20: WARNING: py:obj reference target not found: invert_yaxis/home/circleci/project/lib/matplotlib/axes/_base.py:docstring of matplotlib.axes._base._AxesBase.get_ybound:20: WARNING: py:obj reference target not found: yaxis_inverted/home/circleci/project/lib/mpl_toolkits/mplot3d/axes3d.py:docstring of mpl_toolkits.mplot3d.axes3d.Axes3D.set_xbound:31: WARNING: py:obj reference target not found: invert_xaxis/home/circleci/project/lib/mpl_toolkits/mplot3d/axes3d.py:docstring of mpl_toolkits.mplot3d.axes3d.Axes3D.set_xbound:31: WARNING: py:obj reference target not found: xaxis_inverted/home/circleci/project/lib/mpl_toolkits/mplot3d/axes3d.py:docstring of mpl_toolkits.mplot3d.axes3d.Axes3D.set_xlim:53: WARNING: py:obj reference target not found: invert_xaxis/home/circleci/project/lib/mpl_toolkits/mplot3d/axes3d.py:docstring of mpl_toolkits.mplot3d.axes3d.Axes3D.set_xlim:53: WARNING: py:obj reference target not found: xaxis_inverted/home/circleci/project/lib/mpl_toolkits/mplot3d/axes3d.py:docstring of mpl_toolkits.mplot3d.axes3d.Axes3D.set_ybound:31: WARNING: py:obj reference target not found: invert_yaxis/home/circleci/project/lib/mpl_toolkits/mplot3d/axes3d.py:docstring of mpl_toolkits.mplot3d.axes3d.Axes3D.set_ybound:31: WARNING: py:obj reference target not found: yaxis_inverted/home/circleci/project/lib/mpl_toolkits/mplot3d/axes3d.py:docstring of mpl_toolkits.mplot3d.axes3d.Axes3D.set_ylim:53: WARNING: py:obj reference target not found: invert_yaxis/home/circleci/project/lib/mpl_toolkits/mplot3d/axes3d.py:docstring of mpl_toolkits.mplot3d.axes3d.Axes3D.set_ylim:53: WARNING: py:obj reference target not found: yaxis_inverted

It looks like the warning is that it can't find themat all, rather than that it e.g. sees bothAxes.invert_yaxis andAxes3D.invert_yaxis, which was my first thought.

Sphinx version is different (7.2.4 here, 7.2.6 on main), though only as patch releases, and nothing obviously related in release notes.

mpl-sphinx-theme version is different, though I can't think of a way that should affect this linking behavior.