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, and 25/24 = 1+2*1/48).

I dug into the scale factor more after your comment, and changing two of them to 24/25 made all the baseline images pass without updates! Reduces the size of this MR quite a bit, thank you!

I'll note however that the scale factor in ticker I left at 23/24, because 24/25 was causing an image failure for gridline locations on one of the tests. I'm not quite sure what to make of that, but I do think it's plausibly correct.

@QuLogic do you mean the comments in the code, or in this thread? I'm not quite sure how to concisely describe the scale factors in more detail, as they are rather magic-constanty and I figured them out 50/50 by understanding the code and trial-and-error.

I mean the comments in the code. Saying 0.019965277777777776 = 1/48*23/24 doesn't really seem to explain much more than saying 0.01996... matches mpl3.7 appearance, as I have no idea where 48, 23, or 24 came from. Is the old padding 1/24 and every other number is ±1 or so?

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. The old padding was from these lines: https://github.com/matplotlib/matplotlib/blob/fff2a79ce22ab39bea95067d30438bfdbe47f560/lib/mpl_toolkits/mplot3d/axis3d.py#L230_L232

deltas = (maxs - mins) / 12
mins -= 0.25 * deltas
maxs += 0.25 * deltas

I generally like to err on the side of too much detail in comments, but am happy to take out the extra fractions in the code if you think it's going to be confusing for people.