You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Axes.grid() not honoring specified "zorder" kwarg #5045
Axes.grid() is not honoring a provided custom zorder. Instead the grid's zorder seems to be fixed at some miraculous value in between 2.5 and 2.6 (I could not find a key for grid zorder in rcParams). This can be annoying because than all other artists zorder have to be adjusted around the grid zorder as opposed to only changing the zorder of the grid.
An other option is to just add 2.5 to all of your z-orders.
Yeah, I had to set zorder for anything drawn onto my axes, not such a big deal. It's just a bit puzzling at first (when trying to find out why setting the axes zorder is not working) and then a bit more code (in having to set all other zorders around it).
I don't see this a big problem if it can not be changed easily. But then at least the docs (wherever grid is advertised) should reflect the fact that the zorder is fixed -- currently it's being advertised as a possibility to change as one likes, leading to puzzling moments when trying to use the zorder kwarg.
It would seem reasonable to deprecate axisbelow in favor of simply letting the user set whatever zorder they want on the axes (with a default at 2.5). (This should be easy to do with a proper deprecation warning.)
If we want to keep the functionality available as the axes.axisbelow rcparam, that param should be extended to also accept numeric values, which are simply interpreted as default zorder.
Have there been any changer to this behaviour to date? I stumbled upon this issue after I noticed that I could not influence the order in which minor and major grid lines are drawn (the zorder parameter of plt.grid suggests that this should be possible). Will this possibly be fixed in a future release?
This would have to be part of a major overhaul of the tick and gridline system, which I suspect might have to be just one component of an even more major refactoring, so I think the solution for the foreseeable future is the documentation tweak in #13995.
Activity
tacaswell commentedon Sep 11, 2015
Huh, one part of the reason is that the grid lines are drawn as part of the
axisartists, the other part is that we re-set the zorder of the axis objects inAxes.draw(https://github.com/matplotlib/matplotlib/blob/master/lib/matplotlib/axes/_base.py#L2211).If you do
ax.set_axisbelow(True)it will pin the z-order at 0.5 which might be better for you.An other option is to just add 2.5 to all of your z-orders.
Sadly, it does not look like there is a quick fix for this on the upstream side.
It looks like this code originally came in in 155ca3f to replace having conditional draws before/after the main draw loop.
attn @efiring
megies commentedon Sep 11, 2015
Yeah, I had to set zorder for anything drawn onto my axes, not such a big deal. It's just a bit puzzling at first (when trying to find out why setting the axes zorder is not working) and then a bit more code (in having to set all other zorders around it).
I don't see this a big problem if it can not be changed easily. But then at least the docs (wherever grid is advertised) should reflect the fact that the zorder is fixed -- currently it's being advertised as a possibility to change as one likes, leading to puzzling moments when trying to use the zorder kwarg.
anntzer commentedon Aug 26, 2017
It would seem reasonable to deprecate axisbelow in favor of simply letting the user set whatever zorder they want on the axes (with a default at 2.5). (This should be easy to do with a proper deprecation warning.)
If we want to keep the functionality available as the axes.axisbelow rcparam, that param should be extended to also accept numeric values, which are simply interpreted as default zorder.
Time0o commentedon Apr 20, 2019
Have there been any changer to this behaviour to date? I stumbled upon this issue after I noticed that I could not influence the order in which minor and major grid lines are drawn (the
zorderparameter ofplt.gridsuggests that this should be possible). Will this possibly be fixed in a future release?DOC: explain zorder for gridlines in grid docstring
efiring commentedon Apr 20, 2019
This would have to be part of a major overhaul of the tick and gridline system, which I suspect might have to be just one component of an even more major refactoring, so I think the solution for the foreseeable future is the documentation tweak in #13995.