Fixed on the development branch in this cset: https://hg.savannah.gnu.org/hgweb/octave/rev/a7dfb00d5bf5.

This will be a part of the Octave 6.1 release.  To access the fix sooner download axis.m from the Mercurial development branch and replace your local copy.

Closing report.

I've attached a simple patch that adds a listener to the axes that passes the contour handle into the function so it may be used to adjust the zlim.

The following works about right:

graphics_toolkit qt
figure
[X,Y] = meshgrid(-3:.125:3);
Z = peaks(X,Y);
meshc(X,Y,Z)
axis('equal')

albeit a little clunky.

However, pressing "Autoscale" has a problem.  Although the listener is called, the placement of the contour seems to affect auto-zlim range.  I've lessened the effect by de-activating zlimmode adjustment temporarily, but once it gets turned back on the range readjusts.  In the patch I've printed out the actual value of zlim minimum to illustrate.  I suppose the autoscale is designed to leave a bit of space beyond the data limit even if that data limit falls at a nice whole number.  (Without turning off auto-adjust, the code will get into a short feedback loop where it keeps adjusting until finding a stopping point.)  If someone can think of a way around this auto-adjusted zlim caused by the placement of the contour, let me know (e.g., is there a way to take the particular contour object out of the list of data elements used to determine auto-range?).

(file #41742)

The code that sets the level is here in meshc.m:

    zmin = get (hax, "zlim")(1);
    [~, htmp2] = __contour__ (hax, zmin, varargin{:});

The bad is that there is nothing in axis.m that resets the contour.  The good is that the contour is an hggroup with a parameter for the zlevel.

    kids = get(gca,'children');
    get(kids(1))
    zlevel = -10

Hence we should be able to make things work, for "axis" anyway, but automating something like the following:

figure
[X,Y] = meshgrid(-3:.125:3);
Z = peaks(X,Y);
meshc(X,Y,Z)
axis('equal')
zlevel = min(get(gca,'zlim'))
kids = get(gca,'children');
set(kids(1), 'zlevel', zlevel)

and that does in fact work.  So, any scripts that modify the axes ranges need to go through the list of graphics objects, test if they are contour (if they have the 'zlevel' property, I assume) and change the zlevel property.

That wouldn't be a difficult set of changes to make, but what about the z-range being changed via the mouse?  I don't see any way of changing z limits via the plot, only x and y limits.  Except of one considers the "A" autorange button, then that alters the Z-range.  I've tested Qt plot by printing something in axis.m when the "axis('equal')" is called--unfortunately, when the "Autoscale" is pressed in the Qt plot window that doesn't make its way back to the axis.h routine.  So what to do in that case, I don't know.

Acknowledging the behavior here, and noting that this is "Any" operating system.  Also, the contours disappear in the gnuplot toolkit as well, so that means contour lines are not being handled by gnuplot (since gnuplot handles contours without forcing some z coordinate on the lines...they always are associated with the border) and that its not a real low level function of gl-rendering where the problem lies.

Sort of mid-level routine would be my guess.  But I'm also wondering if there is a design problem in the sense that only the lowest level of plotting can determine what the eventual axis limits will be.  Or maybe the contour drawing needs to be done with one of those feedback functions such that when the user rescales the plot or moves the axes about via the mouse wheel then the Z-position of the contours is changed.  The equivalent concept for gnuplot would be using gnuplot's internal contour commands, because gnuplot is the only code that knows what the final plot limits are.

I found that if you do an autoscale then the contour lines show again.