The relevant code is

which auto-expands the bounds. We actually want auto-expansion for automatically determined bounds, but not for user bounds.

👉 Things to do:

• Check how the expansion is done in 2D. (I assume it works slightly differently and the 3D code was added ad-hoc).
• Implement a way to not expand the bounds if they were set by the user.
• There seems to be an interference between the grid line and the axis line if the axis limits were set explicitly. For below image, I've deactivated the expansion code above and used set_xlim. Note that the xaxis line is blurry.
  

I'd be interested in looking into this

Great @neilZon ! Please let us know if you have any questions (either here or on https://gitter.im/matplotlib/matplotlib )

• Check how the expansion is done in 2D. (I assume it works slightly differently and the 3D code was added ad-hoc).

A default plot immediately sets both _stale_viewlim_* variables to True:

A draw calls _unstale_viewLim():

The _stale_viewlim_* values cause it to get autoscaled:

This inner function is called for each, which does the (much more detailed) 2D bound calculations:

If you call, e.g., set_xlim the _stale_viewlim_x gets set to False which prevents the above:

Meanwhile, axes3d.py has an identical-but-for-z _unstale_viewLim function, but its autoscale_view is wildly different. Normally I'd think it'd be desirable to make the code as dimension-agnostic as possible and share code between them, but I haven't noticed a lot of precedence for that. Is it avoided for some reason?

We are a group of students that have looked into this for a while as part of a course.

Thank you @kentcr for some excellent documentation of the 2D-case. It helped us a lot.

• Implement a way to not expand the bounds if they were set by the user.

Actually, it seems that this is already done in the autoscale_view and the only step needed to get the desired behaviour is to remove these lines:

The autoscale_view adds margins (_xmargin, _ymargin, _zmargin) with to the same logic as in the 2D case. It's a bit of a mystery to us as to why these deltas where added in the beginning. We ran the whole test suite with those lines removed and looked through all the generated images in result_images and it seems to behave properly apart from this:

• There seems to be an interference between the grid line and the axis line if the axis limits were set explicitly. For below image, I've deactivated the expansion code above and used set_xlim. Note that the xaxis line is blurry.

This problem is not correlating with setting the xlim manually but it happens every time a gridline is aligned with the xaxis (only the xaxis however, not the other ones). We tried to solve this problem both by experimenting with the zorder and the order in which the different components of the axis (gridlines, ticks, spines) are drawn but could not find a solution. Does anybody have an idea of what is happening here?

Does anybody have an idea of what is happening here?

It's a y-tick being drawn. If you clear the y-ticks, it disappears:

import matplotlib.pyplot as plt
from mpl_toolkits.mplot3d import Axes3D
fig = plt.figure()
ax = fig.gca(projection=Axes3D.name)
ax.set_yticks([])
ax.set_xlim(0, 0.8)
plt.show()

Further, if you remove the first tick in each axis here...

e.g.

        ticks = self._update_ticks()[1:]

...it fixes this problem, but you lose the gridline where the background planes intersect:

I'd initially hoped to just change _update_ticks() for the y case, but it's actually inherited from the 2D class:

It does seem possible to just change the ticks just for the y-axis, but the obvious ways don't seem very elegant to me. Of course, it's also rather fishy that the 3D YAxis and ZAxis classes are inheriting from the 2D XAxis class, so maybe elegance is a lost cause without more significant changes.

It may also be that the ticks are actually fine and it's some lower-level rendering issue, but I haven't dug that far yet.

Edit: I should say it's actually clear that the ticks are fine, but the gridlines (which are generated from the ticks and put in the xyz0 variable) may also be fine. I haven't dug into whether or not they are drawn when overlapping with the axis on purpose.