Subplots not drawing correctly.

[IMacaulay]

I've been having a problem with subplots. Quite often, when I try to
plot multiple axes in one figure window, one or more of the axes will
fail to draw properly. This generally takes the form of the axes
themselves being missing (labels, plotted data, &c., usually present),
grid lines being missing, or tick marks extending across the whole
axes. I've attached and example (this is towards the worse end of the
spectrum). The behaviour appears to be similar with QT (which I
usually use) and FLTK; Gnuplot doesn't suffer from this, but has other
issues which rule it out, for me. Any suggestions, please, or
work-arounds more practical than only ever plotting one thing in a
window?

I'm using 4.2.2, dated 13th March '18, under Lubuntu 18.04 LTS (NB,
Lubuntu, not Ubuntu). The problem also existed with 16.04 LTS, and
whatever build of Octave I had prior to March.

Thanks,

[w***@wylch.fastmail.fm]

Hi there,

Would be happy to try it here. Can you add some code to try?

Does it happen on screen or only when you save to file? May be an issue
with line thickness in the conversion then.

Cheers,

Willem

[IMacaulay]

Certainly.
The attached example.m is a cut down version of the function that
produced the plot I previously sent, and example.png is cut from a
screen shot of the result of running this on my machine this morning.
I have had so many problems with saving/printing figures in the past,
that now I only use screen shots, which are adequate for most
purposes.
Thanks.

Post by w***@wylch.fastmail.fm
Hi there,
Would be happy to try it here. Can you add some code to try?
Does it happen on screen or only when you save to file? May be an issue
with line thickness in the conversion then.
Cheers,
Willem

[Reed, Darren K. (MSFC-ER42)]

-----Original Message-----
From: Help-octave [mailto:help-octave-bounces+darren.k.reed=***@gnu.org] On Behalf Of IMacaulay
Sent: Friday, October 26, 2018 5:18 AM
To: ***@wylch.fastmail.fm
Cc: help-***@gnu.org
Subject: Re: Subplots not drawing correctly.

Certainly.
The attached example.m is a cut down version of the function that produced the plot I previously sent, and example.png is cut from a screen shot of the result of running this on my machine this morning.
I have had so many problems with saving/printing figures in the past, that now I only use screen shots, which are adequate for most purposes.
Thanks.

Post by w***@wylch.fastmail.fm
Hi there,
Would be happy to try it here. Can you add some code to try?
Does it happen on screen or only when you save to file? May be an
issue with line thickness in the conversion then.
Cheers,
Willem

Hello,
I'm not sure why, but if you move the plot([-70,10],... line in front of hold on; then I think you get what you want.
This is the same as the last two subplots.

subplot(2,2,1);

plot([-70,10],[-70,10],"color",[0.8,0.8,0.8]);
hold on;
plot(mbw_4229_01(6),mbw_4229_01(13),"r");
plot(mbw_4229_02(6),mbw_4229_02(13),"g");
plot(mbw_4229_04(:,6),mbw_4229_04(:,13),"b");
plot(mbw_4229_05(:,6),mbw_4229_05(:,13),"m");


set(gca,"xlim",[-70,10],"ylim",[-70,10]);
xlabel("MBW frost point (^oC)");
ylabel(" frost point (^oC)");
title("Comparison with s/n 4229")
legend("1^{st} October (unheated?)","2^{nd} October (unheated?)",...
"4^{th} October, heated","5^{th} October, heated",...
"location","southeast");
hold off;

Darren

[w***@wylch.fastmail.fm]

Thanks! That helped. It seems to be a bug (that might not be a bug) with
an easy work around.

For the first subplot you place "hold on" before plotting anything. This
creates axes without a "box" (the top and right lines missing).

Fix: move the "hold on" command to after the first plot command.
Attached is the corrected example.

Alternative: after subplot(221) add:

  set(gca, 'box', 'on')

------------

Explanation: When you issue "hold on" without any plot an axis is first
created (axis command). This default axis does not have the box
attribute set to on.

Willem

Post by IMacaulay
Certainly.
The attached example.m is a cut down version of the function that
produced the plot I previously sent, and example.png is cut from a
screen shot of the result of running this on my machine this morning.
I have had so many problems with saving/printing figures in the past,
that now I only use screen shots, which are adequate for most
purposes.
Thanks.

[IMacaulay]

Thanks for the suggestion, but that does not work for me. I have
tried this, in the past, and also drawing all lines (data) in one
horribly long 'plot' command but neither solved the issue. In the
attached example, you'll see that although the first plot is fixed,
the second lacks its x-grid lines. I also tried using drawnow between
each plot, as it seemed, at one point that plots *might* draw
correctly, but get 'damaged' when later ones were drawn, but I suspect
this was not the case.

Post by w***@wylch.fastmail.fm
Thanks! That helped. It seems to be a bug (that might not be a bug) with
an easy work around.
For the first subplot you place "hold on" before plotting anything. This
creates axes without a "box" (the top and right lines missing).
Fix: move the "hold on" command to after the first plot command.
Attached is the corrected example.
set(gca, 'box', 'on')
------------
Explanation: When you issue "hold on" without any plot an axis is first
created (axis command). This default axis does not have the box
attribute set to on.
Willem

Post by IMacaulay
Certainly.
The attached example.m is a cut down version of the function that
produced the plot I previously sent, and example.png is cut from a
screen shot of the result of running this on my machine this morning.
I have had so many problems with saving/printing figures in the past,
that now I only use screen shots, which are adequate for most
purposes.
Thanks.

[Doug Stewart]

hold on;

Post by IMacaulay
Thanks for the suggestion, but that does not work for me. I have
tried this, in the past, and also drawing all lines (data) in one
horribly long 'plot' command but neither solved the issue. In the
attached example, you'll see that although the first plot is fixed,
the second lacks its x-grid lines.

I see the x grid lines in the picture that you attached!
So I don't understand what your problem is.

Doug

Post by IMacaulay
I also tried using drawnow between
each plot, as it seemed, at one point that plots *might* draw
correctly, but get 'damaged' when later ones were drawn, but I suspect
this was not the case.

Post by w***@wylch.fastmail.fm
Thanks! That helped. It seems to be a bug (that might not be a bug) with
an easy work around.
For the first subplot you place "hold on" before plotting anything. This
creates axes without a "box" (the top and right lines missing).
Fix: move the "hold on" command to after the first plot command.
Attached is the corrected example.
set(gca, 'box', 'on')
------------
Explanation: When you issue "hold on" without any plot an axis is first
created (axis command). This default axis does not have the box
attribute set to on.
Willem

Post by IMacaulay
Certainly.
The attached example.m is a cut down version of the function that
produced the plot I previously sent, and example.png is cut from a
screen shot of the result of running this on my machine this morning.
I have had so many problems with saving/printing figures in the past,
that now I only use screen shots, which are adequate for most
purposes.
Thanks.

[w***@wylch.fastmail.fm]

You added "grid on" commands to each subplot command I assume? So this
is something different. I agree with Doug - your plot shows this.

I assume the lines are there, but are faint. The default graphics
toolkit is "qt" and it works fine for me. When I change to "fltk" I also
get the faint lines that are barely visible.

Try this:

close all
graphics_toolkit('qt')
plot_tf_comparisons_0

If that still doesn't work, try different sizes for your plot window,
use the print() command to save to png, or manipulate the grid line
width directly in the properties.

Willem

Post by IMacaulay
Thanks for the suggestion, but that does not work for me. I have
tried this, in the past, and also drawing all lines (data) in one
horribly long 'plot' command but neither solved the issue. In the
attached example, you'll see that although the first plot is fixed,
the second lacks its x-grid lines.

[IMacaulay]

I'm a bit confused, I'm afraid. The top right plot still appears
devoid of x grid lines, as it did before.

I have things set up so that grid lines are the default, which is why
I generally do not have explicit 'grid on' commands.

QT is my normal graphics toolkit, but I get similar behaviour with
FLTK - I've tried this on various occasions, in the past.

Post by w***@wylch.fastmail.fm
You added "grid on" commands to each subplot command I assume? So this
is something different. I agree with Doug - your plot shows this.
I assume the lines are there, but are faint. The default graphics
toolkit is "qt" and it works fine for me. When I change to "fltk" I also
get the faint lines that are barely visible.
close all
graphics_toolkit('qt')
plot_tf_comparisons_0
If that still doesn't work, try different sizes for your plot window,
use the print() command to save to png, or manipulate the grid line
width directly in the properties.
Willem

Post by IMacaulay
Thanks for the suggestion, but that does not work for me. I have
tried this, in the past, and also drawing all lines (data) in one
horribly long 'plot' command but neither solved the issue. In the
attached example, you'll see that although the first plot is fixed,
the second lacks its x-grid lines.

[w***@wylch.fastmail.fm]

Attached is what it looks like here, no problem. The lines are very fine
and in your plots you can see intensity changes near the cross-over
points, suggesting you have an issue with aliasing of pixels. I would
suggest you investigate along that direction - I doubt there is anything
wrong on the octave end at this point.

W


Are you running

Post by IMacaulay
I'm a bit confused, I'm afraid. The top right plot still appears
devoid of x grid lines, as it did before.
I have things set up so that grid lines are the default, which is why
I generally do not have explicit 'grid on' commands.
QT is my normal graphics toolkit, but I get similar behaviour with
FLTK - I've tried this on various occasions, in the past.

[IMacaulay]

Thanks, that makes more sense - the plot you attach is a different one
from what I thought you were referring to.

I think it very unlikely to be an aliasing issue because:
- the lines that do appear, are always sharp and single-pixel,
suggesting no background interpolation before display, nor are any
possible aliasing artefacts visible;
- in a grid of subplots with identical axes, lines can be absent from
one set, but present and sharp in others in the same row and column;
- the issue shows no sensitivity to figure window size or location;
- the issue may appear in different places on successive runs using
the same figure window;
- gnuplot produces similarly fine lines reliably ('though is grim in
other ways);
- the problem manifests itself identically on different monitors.

If, however, you cannot reproduce the problem, then of course you
cannot do anything about it.

Thanks anyway.

Post by w***@wylch.fastmail.fm
Attached is what it looks like here, no problem. The lines are very fine
and in your plots you can see intensity changes near the cross-over
points, suggesting you have an issue with aliasing of pixels. I would
suggest you investigate along that direction - I doubt there is anything
wrong on the octave end at this point.
W
Are you running

Post by IMacaulay
I'm a bit confused, I'm afraid. The top right plot still appears
devoid of x grid lines, as it did before.
I have things set up so that grid lines are the default, which is why
I generally do not have explicit 'grid on' commands.
QT is my normal graphics toolkit, but I get similar behaviour with
FLTK - I've tried this on various occasions, in the past.