MNT: Commonize 3D zmargin handling with x and y axes - #31287
MNT: Commonize 3D zmargin handling with x and y axes#31287scottshambaugh wants to merge 2 commits into
Conversation
ac5e4d3 to
b4732a8
Compare
a12522b to
f01afb5
Compare
|
I'm pretty sure many of these tests that are changed here have a "Remove this line when the image is regenerated." comment in them that should be heeded. |
4a261f9 to
a12357a
Compare
|
Good catch, took those off of the 5 that had it. Also took off the tolerance on one, I'll see if it needs to be added back after cross-platform CI. Edit: looks good |
|
I haven't checked, but I'm not sure if some of these changes will conflict with the text overhaul branch? I guess we need some decision on some of the questions in the original post though. |
|
Some images will need to be regenerated but I don't see the code changes conflicting with text edits. To summarize, the choice that needs to be made is between these. (1) is what's in right now, but I don't care too much either way:
|
a12357a to
8a6f667
Compare
8a6f667 to
c4db27e
Compare
c4db27e to
696b947
Compare
696b947 to
c99e8d6
Compare
I have a slight preference for this option to avoid the subtle squishing |
|
Talked about this a bit on the call today, general sentiment was to change default zmargin to 0 to keep most plot types "unsquished" and looking the same as they do now (scatter and logscales would change appearance). And since fixing this means a visual change to something, so we might as well pick the "prettier" option. But some question around if it needs a formal deprecation. @timhoffm thoughts? |
PR summary
Closes #31213
The 3D z axis margin was handled inconsistently from the x and y axes, leading to special casing and inconsistent visual results even with equal values for the
axes.[x/y/z]marginrcparams. I put this change somewhere between maintenance and a bugfix.This requires regenerating a good number of baseline images (about half of 3d images), but I don't see a good way around that.
If people don't like the results being "squished" then the right way to handle this would be to keep these changes and set
axes.zmargin = 0in the rcparams (scatter plots and nonlinear scales would still change appearance). There's some justification for this because the x:y:z aspect ratio is 4:4:3 by default, so that would be "unsquishing" in a way. But this is always controllable by the user viaset_box_aspectand axis limits. I don't feel too strongly either way.AI Disclosure
PR checklist