bugGNU Octave - Bugs: bug #47974, Visual differences between gnuplot...

 
 

bug #47974: Visual differences between gnuplot and OpenGL toolkits

Submitted by:  Rik <rik5>
Submitted on:  Sun 22 May 2016 05:31:31 AM UTC  
 
Category:  Plotting with gnuplot Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Matlab Compatibility
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  Closed
Release:  dev Operating System:  GNU/Linux

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

( Jump to the original submission)

Sun 02 Oct 2016 02:08:44 PM UTC, comment #83: 

I pushed your patch here (http://hg.savannah.gnu.org/hgweb/octave/rev/6e492d3d2e1e).  The gnuplot interface for Octave has been so improved at this point, thanks mostly to Dan Sebald, that I'm going to close this report.  If there are remaining inconsistencies they can get their own bug report.

Rik <rik5>
Project Administrator
Sun 02 Oct 2016 02:11:17 AM UTC, comment #82: 

Attached is a fix for the patch problems introduced in the "mapcdata changeset".  Try the two examples from https://savannah.gnu.org/bugs/?47974#comment81 after the change.

Again, I'm not sure every corner case is covered but I don't want to scale the depths of this and be tempted to make big changes.

(file #38640)

Dan Sebald <sebald>
Sat 01 Oct 2016 04:11:40 PM UTC, comment #81: 

Some good news, I re-ran all of the demos that originally motivated this report and they now all pass.

The remaining differences seem to be in the patch function which is a very difficult to get right.

Some differences:

demo patch 6
error: vertical dimensions mismatch (1x3 vs 1x1)
error: called from
    __gnuplot_draw_axes__ at line 824 column 34
    __gnuplot_draw_figure__ at line 172 column 17
    __gnuplot_drawnow__ at line 86 column 5

And

v = [2 0; 3 0; 3 1];
f = [1 2 3];
c = [1 0 0; % red
    0 1 0; % green
    0 0 1]; % blue
patch('Faces',f,'Vertices',v,'FaceVertexCData',c,...
    'EdgeColor','flat','FaceColor','none','LineWidth',2);

which doesn't produce red, green, and blue lines.

Rik <rik5>
Project Administrator
Sat 01 Oct 2016 12:23:28 AM UTC, comment #80: 

I pushed a cset that takes care of the case where the clim range is 0 (http://hg.savannah.gnu.org/hgweb/octave/rev/6b2a1b2c1576).

Rik <rik5>
Project Administrator
Fri 30 Sep 2016 11:59:47 PM UTC, comment #79: 

markeredgecolor can either be a color specification, "auto", or "none".  I don't thing there is a way to get multi-colored markers so I think the patch is just fine.  I pushed it here http://hg.savannah.gnu.org/hgweb/octave/rev/d5e775944809.

This example, which used to cause a hard error for me, now completes.  But the coloring is wrong.  It should be that one line sigment is RED, one GREEN, and one BLUE.

v = [2 0; 3 0; 3 1];
f = [1 2 3];
c = [1 0 0; % red
    0 1 0; % green
    0 0 1]; % blue
patch('Faces',f,'Vertices',v,'FaceVertexCData',c,...
    'EdgeColor','flat','FaceColor','none','LineWidth',2);

Rik <rik5>
Project Administrator
Fri 30 Sep 2016 07:38:19 PM UTC, comment #78: 

Attached is a fix.  I left in the case of "palette" for the markeredgecolor, but I'm not sure if that can be reached:

octave:7> set (h, "markeredgecolor")
[ {auto} | none ]

In the above an RGB triple is also valid.  The scenario where "palette" would be used is if the marker edges were to be multicolored.  Is there such a scenario ("flat" maybe)?

(file #38633)

Dan Sebald <sebald>
Fri 30 Sep 2016 06:35:20 PM UTC, comment #77: 

I missed the bug in #75, sorry.  Hmm, here's what is different between the two files created with drawnow (there is another difference after the binary data, but it looks fine):

sebald@moorglade ~/octave/bug_49130 $ diff -u yellowjunk-good.gp  yellowjunk.gp
--- yellowjunk-good.gp        2016-09-30 13:26:32.875372459 -0500
+++ yellowjunk.gp        2016-09-30 13:26:41.139372540 -0500
@@ -48,7 +48,11 @@
unset logscale;
set clip two;
set style line 9 default;
-set style line 9 linecolor rgb "#0000ff" dashtype '_ ' linewidth 0.500000 pointtype 6 pointsize 2.000000;
+set style line 9 linecolor rgb "#0000ff" dashtype '_ ' linewidth 0.500000;
+set style line 10 default;
+set style line 10 linecolor rgb "#4db300" pointtype 7 pointsize 2.000000;
+set style line 11 default;
+set style line 11 palette pointtype 6 pointsize 2.000000;
set pm3d implicit;
unset hidden3d;
set xrange [0.000000000000000e+00:1.000000000000000e+01];

I think that "palette" in line 11 is the source of the problem.  gnuplot is expecting a third column for that style (the index to the color map).  I don't see why we should be using the palette, however.  I'll have a look...

Dan Sebald <sebald>
Fri 30 Sep 2016 06:01:29 PM UTC, comment #76: 

@Dan: Ping!  Could you take a look at the sample code in comment #75 which is still failing for me (9/30/16) with the error

          line 0: Not enough columns for variable color

Rik <rik5>
Project Administrator
Fri 23 Sep 2016 03:10:18 PM UTC, comment #75: 

Item 1 : See Matlab documentation for https://www.mathworks.com/help/matlab/ref/chartline-properties.html#property_MarkerEdgeColor.  At least for lines, "auto" means use the "Color" property.  I tested and your patch already works as expected.  The documentation for MarkerFaceColor and "auto" seems wrong.  I would ignore it.  With your patch gnuplot replicates what the qt and fltk toolkits are doing so I think that is good enough.  Octave itself will have consistency across the three toolkits.

Item 2 : I can only test back to 4.6.6, but it works for me there.  Go ahead and open up a specific bug report for gnuplot 4.4 weirdness.

I pushed your patch here (http://hg.savannah.gnu.org/hgweb/octave/rev/bcd2630c14f3) because it does seem to be a vast improvement.

One bug I still encounter is shown by the following code.

close all
graphics_toolkit gnuplot
h = plot (1:10, "o--b");
set (h, "markerfacecolor", "y")
          line 0: Not enough columns for variable color

And the resulting plot is blank.

Rik <rik5>
Project Administrator
Thu 22 Sep 2016 07:53:15 PM UTC, comment #74: 

I'm attaching a new version of the patch that works (almost) for gnuplot 4.4.0 to present.  This also solves several bugs that we have yet to run across.  Here is the test sequence I used to check behavior:

demo line 1
demo waterfall 1
kids = get(gca,'children');
set(kids(1),'marker','o');
set(kids(1),'linestyle','none');
set(kids(1),'markeredgecolor','b');
set(kids(1),'linestyle','-');
set(kids(1),'marker','none');
set(kids(1),'edgecolor','r');
set(kids(1),'marker','*');
set(kids(1),'markeredgecolor','flat');
set(kids(1),'linestyle','none');
set(kids(1),'marker','none');

I know this isn't perfect yet, but it is close.  It may affect things elsewhere, but hopefully not too bad.  Here are the two things bothering me still:

1) I don't understand exactly what markeredgecolor and markerfacecolor "auto" means.  Is it supposed to get the color from its parent axes?  So, I just put in some conditional tests for "auto" setting so that it appears to come out as expected without really understanding it.  There may need to be some

strcmp (obj.markeredgecolor, "auto")

types of code shuffled around.

2) In gnuplot 4.4.0 I'm finding that the surface face color is yellow rather than white.  I don't understand why, short of a bug in gnuplot 4.4.0.  So, rather than try to fix this in the attached patch, I'd prefer to open a separate bug report for the random surface color in gnuplot 4.4.0 and investigate if there might be an alternative syntax to work around this issue.

(file #38589)

Dan Sebald <sebald>
Wed 21 Sep 2016 07:48:50 PM UTC, comment #73: 

There looks to be some type of bug in 4.6.6.  I just tried 4.6.6 here.  I used "drawnow" to generate some gnuplot code when Octave is using 4.6.6.  That code has dashed lines under gnuplot 4.6.6 but looks correct under gnuplot 5.0.  I think what is wrong with 4.6.6 is that it doesn't seem to recognize the default declaration in the following gnuplot code:

set style line 63 default;
set style line 63 linecolor rgb "#d9262626" linetype 1 linewidth 0.500000;
[snip]
, "-" binary format='%float64' record=53x1 using ($1):($2):($3):($4) title "" with lines palette  \

If I force the linetype, i.e.:

, "-" binary format='%float64' record=53x1 using ($1):($2):($3):($4) title "" with lines lt 1 palette  \

then the waterfall plot looks correct.

If x11 terminal looks different for you under some circumstances it is just pointing out what the long-term complaint of gnuplot users was: dash patterns were never coming out as expected.  It used to be that dash pattern, or generally linetype, was terminal specific.  Still is, I guess.  And the way to set X11 line patterns was to edit the file .Xdefaults.  No one ever thought to get into so much detail with gnuplot and X11 so eventually gnuplot developers introduce "linetype" and "dashtype" options to give better control.

Let me look at this over the next day or two and see if I can add the "lt #" option without too much extra effort.

Dan Sebald <sebald>
Wed 21 Sep 2016 06:44:56 PM UTC, comment #72: 

@Dan: The patch works for me with 'wxt', 'qt', or 'x11' and gnuplot 5.0.1.  When I try it with 'qt' and gnuplot 4.6.6 I find that there is no change and that waterfall still has problems.  Is that expected?  Your patch is no worse than the existing behavior, but it also doesn't fix the problem.  I can't try 'wxt' because I don't have it compiled in for 4.6.6.

Separately, when I try "x11" in 4.6.6 there appear to be no working linestyles.  Is this a known problem with the x11 terminal?  I used 'demo line 1' and all the lines are solid.

Rik <rik5>
Project Administrator
Mon 19 Sep 2016 08:47:32 PM UTC, comment #71: 

Having done a mod to gnuplot_toolkit color processing this weekend, I was reminded there is at least one issue in this bug report that is unresolved: the line pattern.

The polar plot examples, seem to have changed, so the better illustration is now:

demo polar 3
demo waterfall 1

Or

demo line 1
demo waterfall 1

The odd thing is that the above needs to be entered separately at the command line.  If I place the two lines in an external file and call that script, the dotted line does not appear in the waterfall.  Maybe that has something to do with the underlying manner in which Octave creates a gnuplot process for each different figure--but not relevant here.

The solution to this incorrect line pattern seems to be straightforward.  I think that "linetype" is a persistent gnuplot setting, i.e., "reset" in gnuplot does not alter the line styles for any lines set using "linetype".  I can't think of why Octave would ever want gnuplot to have a persistent setting of this particular characteristic.  Instead, if we stick to the use of "set style line" and use "linestyle", we should be fine.  That is, Octave's strategy seems to be a completely clean slate with each new gnuplot figure.

A simple illustration is to change _gnuplot_has_feature_.m in a way that forces the use of "linestyle" rather than "linetype".  I.e.,

diff --git a/scripts/plot/util/private/__gnuplot_has_feature__.m b/scripts/plot/util/private/__gnuplot_has_feature__.m
--- a/scripts/plot/util/private/__gnuplot_has_feature__.m
+++ b/scripts/plot/util/private/__gnuplot_has_feature__.m
@@ -44,7 +44,7 @@ function res = __gnuplot_has_feature__ (
       ## Don't throw an error if gnuplot isn't installed
       gnuplot_version = "0.0.0";
     end_try_catch
-    versions  = {"4.4", "4.6", "4.6", "5.0", "4.6", "4.6", "5.0", "5.0", "5.0"};
+    versions  = {"4.4", "4.6", "10.6", "5.0", "4.6", "4.6", "5.0", "5.0", "5.0"};
     operators = {">=" , ">=" , ">=" , ">=" , ">=" , ">=" , ">=" , ">=" , ">=" };
     have_features = false (size (features));
     for n = 1 : numel (have_features)

Attached is a patch that gets ride of all the code hunks in _gnuplot_draw_axes_.m (the only file using "linetype") of the form

if (__gnuplot_has_feature__ ("linetype"))

(file #38557)

Dan Sebald <sebald>
Sat 25 Jun 2016 07:42:33 AM UTC, comment #70: 

This bug report:

https://savannah.gnu.org/bugs/?48200

has a patch attached:

https://savannah.gnu.org/bugs/download.php?file_id=37532

that is related to printing (in general) and should be considered for pushing to the canonical repository.  It allows a background of 'none' and fixes a bug if there are no handle elements for properties.  (But doesn't fix the bug associated with that ticket...just something I came across when looking at the related code.)

We wondered why exactly the background color is changed to white when printing to a hardcopy, but I think in any case one should be able to turn off the background with 'none'.

Dan Sebald <sebald>
Mon 20 Jun 2016 05:07:09 PM UTC, comment #69: 

The gnuplot toolkit is sort of doing these things already.  E.g.,

      case "."
        pt = pt2 = "7";
        if (isfield (obj, "markersize"))
          obj.markersize /= 3;
        else
          obj.markersize = 5;
        endif

and

    if (! isequal (pt, pt2) && isfield (obj, "markerfacecolor")
        && ! strcmp (obj.markerfacecolor, "none"))

Just how accurate this is behaving overall though, in terms of pixels, isn't something I've looked at.  I'll follow bug https://savannah.gnu.org/bugs/?48208 to see if consensus emerges.

Dan Sebald <sebald>
Mon 20 Jun 2016 04:29:15 PM UTC, comment #68: 

@Dan: I pushed your changeset for markers here (http://hg.savannah.gnu.org/hgweb/octave/rev/6be06f0c7463).

Also, take a look at bug #48208 where there has been a lot of discussion on how Octave is implementing markers.  In general, the markers which don't have an interior, use the "Color" property to determine their color when "MarkerEdgeColor" is set to "auto".  If "MarkerEdgeColor" is set to a value then it overrides everything.  There is no concept of "MarkerFaceColor" for markers without an interior.

As a second point, the plotted size for the '.' marker should be 1/3rd of whatever the calculated marker size is.  This applies only to the dot '.' marker.

Rik <rik5>
Project Administrator
Mon 20 Jun 2016 07:31:04 AM UTC, comment #67: 

Dmitri found that '.' point type is treated as having a face color when it shouldn't, i.e.,

plot(randn(3), ".y", "markersize", 24, "markeredgecolor", "k")

I then investigated further and found that 'none' marker edge color causes a gnuplot error because of missing the plot style in the command, i.e.,

plot(randn(3), "+r", "markersize", 24, 'markeredgecolor', 'none')

The attached patch address both of these.

However, there is a similar construct in the code still regarding patches.  Do patches have MarkerEdgeColor and MarkerFaceColor?  I don't understand that.

(file #37528)

Dan Sebald <sebald>
Thu 09 Jun 2016 04:00:10 PM UTC, comment #66: 

Doesn't pay to bisect because linestyle was probably never exactly correct, and it shouldn't be difficult to isolate the linestyle issue.

Dan Sebald <sebald>
Thu 09 Jun 2016 03:52:23 PM UTC, comment #65: 

@Dan: I pushed the cset for polar plots here (http://hg.savannah.gnu.org/hgweb/octave/rev/c0a552e71ceb).

The problem with linestyles precedes this cset.  I could try to use hg bisect to find it, but it is probably easier just to fix it.  When someone does a clf in Octave, or otherwise creates a new plot, the linestyles should be reset.

Another example, which may be easier to debug:

demo line 1
demo waterfall 1

The line demo uses all 4 linestyles.  It appears to be the fourth line in the waterfall that is incorrect.

Rik <rik5>
Project Administrator
Thu 09 Jun 2016 06:14:06 AM UTC, comment #64: 

I discovered another bug, after the previous changeset is applied.

demo polar 1
demo waterfall

The waterfall plot comes out with dotted lines for six or seven of the first lines.  I suppose the polar plot assigns line type characteristics and they aren't unset before the waterfall is done.

Dan Sebald <sebald>
Thu 09 Jun 2016 06:08:46 AM UTC, comment #63: 

I made a silly assumption that the text object's parent was an axis object.  Of course that's not always true.  Attached is a fix and extra simplification.

(file #37437)

Dan Sebald <sebald>
Wed 08 Jun 2016 10:48:45 PM UTC, comment #62: 

I'm getting new errors after this cset

changeset:   21832:7fe10fcd8370
user:        Daniel J Sebald <daniel.sebald@ieee.org>
date:        Fri Jun 03 16:15:01 2016 -0500
summary:     For gnuplot, change 3D plot title default location and unit meaning (bug #47974).

Code to reproduce:

close all
graphics_toolkit gnuplot
demo polar 1
polar example 1:
clf;
theta = linspace (0,2*pi,1000);
rho = sin (7*theta);
polar (theta, rho);
title ('polar() plot');

error: get: unknown hggroup property yaxislocation
error: called from
    __gnuplot_draw_axes__>do_text at line 2654 column 3
    __gnuplot_draw_axes__ at line 1320 column 9
    __gnuplot_draw_figure__ at line 172 column 17
    __gnuplot_drawnow__ at line 86 column 5

Rik <rik5>
Project Administrator
Wed 08 Jun 2016 10:30:00 PM UTC, comment #61: 

@Dan: I pushed the cset for box on/off and coloring of axes (http://hg.savannah.gnu.org/hgweb/octave/rev/7da4671f3a5b).

Rik <rik5>
Project Administrator
Wed 08 Jun 2016 06:27:05 PM UTC, comment #60: 

It seems that the fix from comment #53 fixed also bug #38152.

Avinoam Kalma <avinoam>
Project Member
Tue 07 Jun 2016 06:17:24 AM UTC, comment #59: 

Regarding https://savannah.gnu.org/bugs/?47974#comment56

OK, attached is a much smaller changeset for border on/off and tick color.

I created a patch for gnuplot that adds color control for the tics and axis:

https://sourceforge.net/p/gnuplot/feature-requests/446/

That will obviate the faux color axes in patch

https://savannah.gnu.org/support/download.php?file_id=37367

anyway.  Rather than hold off until that gnuplot changeset is incorporated, we'll apply the new patch here and revisit this at a later time, as it will only be a simple patch of maybe a few lines (e.g., check if the gnuplot version is recent enough, then add "linecolor '0xABCDEF' the "set %ctic" command).

(file #37415)

Dan Sebald <sebald>
Mon 06 Jun 2016 11:46:26 PM UTC, comment #58: 

More checking using the Matlab patch examples.  This one is supposed to produce an interpolated facecolor.

x = [2 5; 2 5; 8 8];
y = [4 0; 8 2; 4 0];
c = [0 3; 6 4; 4 6];
figure
patch(x,y,c)
warning: "interp" not supported, using 1st entry of cdata
warning: called from
    __gnuplot_draw_axes__ at line 775 column 24
    __gnuplot_draw_figure__ at line 172 column 17
    __gnuplot_drawnow__ at line 86 column 5
warning: "interp" not supported, using 1st entry of cdata
warning: called from
    __gnuplot_draw_axes__ at line 775 column 24
    __gnuplot_draw_figure__ at line 172 column 17
    __gnuplot_drawnow__ at line 86 column 5
colorbar

Interpolation is also not supported for edgecolor.

V = [0 0;
1 0;
1 1;
0 1]
set (hp, 'facecolor', 'none')
set (hp, 'linewidth', 5)
set (hp, 'facevertexcdata', [1 0 0; 0 1 0; 0 0 1; 1 0 1])
set (hp, 'edgecolor', 'flat');  # WORKS
set (hp, 'edgecolor', 'interp') # DOES NOT WORK

Rik <rik5>
Project Administrator
Mon 06 Jun 2016 11:23:03 PM UTC, comment #57: 

@Dan: I pushed the cset for title positioning here (http://hg.savannah.gnu.org/hgweb/octave/rev/7fe10fcd8370).

Rik <rik5>
Project Administrator
Mon 06 Jun 2016 11:12:40 PM UTC, comment #56: 

@Dan: I reviewed the patch for 'box off' which also incorporates coloring of the axes, but not the tick marks.  You are right, I find it odd when sometimes the axis is one color, sometimes it is missing if I rotate the plot, and sometimes it is black if I use 'box on'.  I think it is best to just color the tick labels and call it a day.  I'll push the slimmed down patch whenever you upload it.

Rik <rik5>
Project Administrator
Fri 03 Jun 2016 09:46:19 PM UTC, comment #55: 

ezsurf : #3 : position of titles is within the plot, rather than above it.

=====

Here's a patch to address the title placement in 3D plots (2D remains the same).

I've concluded this is the same issue as some of the other sizing peculiarities.  This originates from gnuplot and its new behavior with 5 series in which the sizing was changed slightly.  Roughly speaking, when "set {}margin" is used, the size of the 3D plot is now about sqrt(3) larger than it used to be:

https://sourceforge.net/p/gnuplot/bugs/1802/

I'm hoping this can be changed, but in lieu of that, it's also true that it is difficult to adjust title placement because gnuplot only has relative adjust for its title.  None of the Octave units:

>> set(ht, "units")
[ centimeters | {data} | inches | normalized | pixels | points ]

really lends itself to relative placement.  Nor, I should add, do these units help in anyway for absolute placement (i.e., gnuplot's "screen" coordinate system) in order to place a gnuplot label that is fixed rather than rotating with the view (i.e., non roving).

So, the attached patch is the best I could do, and I actually think it isn't too bad.  I've used a label for the title instead of "set title".  The advantage is that absolute placement can be used, the existing text code can be re-used, and as a consequence there might be some extra features like boxed text that comes along with that.

The quirk is that I hijacked the role of the text object's "units".  "normalized" now means screen position relative to plot 2D position.  Perhaps I don't understand all the "centimeters", etc., but certainly "data" is a kind of clumsy way of positioning a title.  That property has to be recomputed with every mouse rotation in the Qt toolkit.  So, what I've done is better than nothing, and it is actually pretty easy to use.

Try commands one at a time like:

sombrero
ht  = title("Sombrero")
[rotate view using mouse]
demo ezsurf
[enter a couple times to example #3]
set (get(gca, "title"), "position", [0.5, 0.95 0])
pos = get(gca, "position")
pos(4) = 0.75
set (gca, "position", pos)
set (get(gca, "title"), "position", [0.5, 1.04 0])

So, there is some control of things here so that the user can achieve an end result--although the default settings may not be the best because of that gnuplot 5.x behavior.  I think as we clear up the remaining few visual differences, what remains will be size issue for which Ben can fine tune things in that _actual_axis_position_() function.

(file #37383)

Dan Sebald <sebald>
Fri 03 Jun 2016 05:06:56 AM UTC, comment #54: 

Rik, attached is a patch to address the box on/off problems.  This isn't quite commit-ready, as I'd like you to evaluate the behavior between two options.  Given that, you can probably guess I couldn't quite achieve the desired end.  Gnuplot has color control of tick annotation, but not for ticks themselves or axes.  I tried pretty hard to use gnuplot's programming scripts to use colored arrows for axes, as was done for the 2D case.  Unfortunately, the arrows don't rove the way that tick marks do in 3D.  To illustrate, I've done the following:

For box on, it's pretty much conventional gnuplot.  No color control of axes, but there is color control for tick annotation.  The mouse-driven rotation works sensibly for this.

For box off, I've put the following selection in the code:

  elseif (0)  ## No box, but no color axes
    fputs (plot_stream, "set border 0x15;\n");
    mirrorstr = "nomirror";
  else        ## Color axes, but non-rototable with mouse

The first case is a behavior similar to 'box'-'on'.  The borders rove with the annotation/ticks--at least for positive x-axis rotation.  Go to negative x-axis rotation though and the lines and annotation won't match on the same axis.  This is a gnuplot thing...I think that is something I discussed with gnuplot developers in the long past.

The second case I'd like you to try.  It at least gives color axes, and if all one does is enter the viewing angle via command line, it's correct.  But once one does mouse rotation, they'll see what the problem is.  The axes "arrows" are always in front and don't rove.  Here's what I've been using to test:

demo waterfall
[Cntrl-C to break after first plot]
set(gca, 'xcolor', 'red')
set(gca, 'ycolor', 'green')
set(gca, 'zcolor', 'blue')
set(gca, 'view', [0, 30])
set(gca, 'view', [90, 30])
set(gca, 'view', [180, 30])
set(gca, 'view', [270, 30])
set(gca, 'view', [360, 30])

Do some rotations with the mouse.

I've a feeling you'll prefer the case where it is only black lines but the tick text is color.  (The changeset comment reflects that option.)  If so, there's a good bit of code that can be removed from the patch.  And I will propose to gnuplot developers that options be added for controlling axis and tick color.  (The whole border structure can be changed color, but not individual axes.)

Frankly, I've never grown to become a fan of roving ticks and annotation.  I'd prefer that the highlight axes be fixed and rotate behind the surface.  With mirrored tick marks, the fixed axes gives a good frame of reference.  After the ticks bounce from axis to axis, I'm soon disoriented and have to look hard at the direction of units.

(file #37367)

Dan Sebald <sebald>
Thu 02 Jun 2016 10:00:48 PM UTC, comment #53: 

@Dan: Pushed the data aspect ratio patch here (http://hg.savannah.gnu.org/hgweb/octave/rev/a4c744194bbb).

Rik <rik5>
Project Administrator
Thu 02 Jun 2016 05:10:58 PM UTC, comment #52: 

Rik, here's a patch for the data aspect ratio (squashy-ness) of isosurface #1.  I resisted the urge to yank all the code prior to is that uses obj.dataaspectratio--that might lead to a bigger project.  gnuplot just doesn't have the fine control on this that Octave is asking for--well not easy, anyway.  Only setting the aspect ratio in xy or xyz is possible.  Try

demo isosurface
set(gca, 'dataaspectratiomode', 'auto');
set(gca, 'dataaspectratiomode', 'manual');
set(gca, 'dataaspectratio', [1 1 10]);
set(gca, 'dataaspectratio', [1 2 10]);

Well, you can see it sort of behaves as desired, but I'm not sure really.  The issue with this originates from this line in the existing code:

    sz_str = sprintf ("set size %s %g, %g;\n", sz_str, pos(3:4));

So, even if I could fine tune sizing (and I'm not 100% sure on that), it should probably wait until after

  pos = __actual_axis_position__ (h);

is cleared up with Ben.  In the mean time, what I attached might be a temporary fix.

The border will have to be in another patch.  Border is another bit tricky coding because I'm not quite sure where the annotated axes exist for a particular view so the borders to remove may vary.

(file #37358)

Dan Sebald <sebald>
Thu 02 Jun 2016 04:58:01 PM UTC, comment #51: 

I applied your patch here (http://hg.savannah.gnu.org/hgweb/octave/rev/43980d664e2d).  Rather than call the bitshift function every time the _gnuplot_draw_axes_ function is called

bitshift(1,0), bitshift(1,8), bitshift(1,16)

I used constants that will be evaluated just once when the function is parsed.

0x1, 0x100, 0x10000

Rik <rik5>
Project Administrator
Thu 02 Jun 2016 04:29:55 PM UTC, comment #50: 

Sorry, getting used to Mint file selector.  Correct file this time.

(file #37357)

Dan Sebald <sebald>
Thu 02 Jun 2016 04:15:32 PM UTC, comment #49: 

@Dan: Could you upload your last patch again?  It was uploaded as a .swp file and is binary, not text.

Rik <rik5>
Project Administrator
Thu 02 Jun 2016 02:44:57 PM UTC, comment #48: 

Attached is a small patch to fix this particular patch edgecolor problem.  There are probably other situations where color can be specified as an RGB triad rather than palette indexing, but let's get on the right track first instead of making large-scale changes.

(file #37355)

Dan Sebald <sebald>
Thu 02 Jun 2016 03:54:52 AM UTC, comment #47: 

Oh, keep the patch example here for now.  Here is a fix for the data error:

diff --git a/scripts/plot/util/private/__gnuplot_draw_axes__.m b/scripts/plot/ut
--- a/scripts/plot/util/private/__gnuplot_draw_axes__.m
+++ b/scripts/plot/util/private/__gnuplot_draw_axes__.m
@@ -1035,7 +1035,7 @@ function __gnuplot_draw_axes__ (h, plot_
              if (ischar (color))
                if (! isnan (xcol) && ! isnan (ycol) && ! isnan (zcol))
                  data{data_idx} = [[xcol; xcol(1)], [ycol; ycol(1)], ...
-                                   [zcol; zcol(1)], [ccol; ccol(1)]]';
+                                   [zcol; zcol(1)], [ccol; ccol(1,:)]]';
                else
                  data{data_idx} = [xcol, ycol, zcol, ccol]';
                endif
@@ -1053,7 +1053,7 @@ function __gnuplot_draw_axes__ (h, plot_
              if (ischar (color))
                if (! isnan (xcol) && ! isnan (ycol))
                  data{data_idx} = [[xcol; xcol(1)], [ycol; ycol(1)], ...
-                                   [ccol; ccol(1)]]';
+                                   [ccol; ccol(1,:)]]';
                else
                  data{data_idx} = [xcol, ycol, ccol]';
                endif

but it doesn't produce a correct result.  I suspect it is because the using clause is defined as

               usingclause{data_idx} = sprintf ("record=%d using ($1):($2):($3)", columns (data{data_idx}));

which isn't enough fields for x, y, cr, cg, cb.  I will take a look at this later.

Dan Sebald <sebald>
Wed 01 Jun 2016 11:59:17 PM UTC, comment #46: 

There are a whole set of examples of the use of the patch function at http://www.mathworks.com/help/matlab/ref/patch.html.  I started trying some of them with the gnuplot toolkit and I run in to hard errors, not just visual differences.  For example,

v = [2 0; 3 0; 3 1];
f = [1 2 3];
c = [1 0 0; % red
    0 1 0; % green
    0 0 1]; % blue
patch('Faces',f,'Vertices',v,'FaceVertexCData',c,...
    'EdgeColor','flat','FaceColor','none','LineWidth',2);
error: vertical dimensions mismatch (3x3 vs 1x1)
error: called from
    __gnuplot_draw_axes__ at line 1055 column 32
    __gnuplot_draw_figure__ at line 172 column 17
    __gnuplot_drawnow__ at line 86 column 5

I can file a new bug report about this, or continue on in this one.  What is the preference?

Rik <rik5>
Project Administrator
Wed 01 Jun 2016 11:46:47 PM UTC, comment #45: 

Okay, I applied your patch to reinstate the N_tup variable here (http://hg.savannah.gnu.org/hgweb/octave/rev/0eefa882bcc7).

Rik <rik5>
Project Administrator
Wed 01 Jun 2016 11:26:11 PM UTC, comment #44: 

Wait, that can't be right.  N_tup determines the width of the data.  I must have deleted too much... Attached is a patch to restore N_tup and the pre-assigned zz data matrix.

Regarding the inner loop, I think this is correct.  My understanding--without looking into it too deeply--was that the style is typically 1 string within the cell, possibly 2.  For example, maybe length 2 would be used for lines + points, e.g. "-*g", if I'm recalling the format syntax correctly.

(file #37347)

Dan Sebald <sebald>
Wed 01 Jun 2016 10:44:36 PM UTC, comment #43: 

I applied the patch here (http://hg.savannah.gnu.org/hgweb/octave/rev/ddd00394d4fe).

I also removed this

if (flat_interp_edge)
  N_tup = 4;
else
  N_tup = 3;
endif

because I couldn't find anywhere that N_tup was used.

In addition, this for loop

for i_stl = 1:length (style)

is now within this larger for loop

for np = 1:num_pass

Was that intended?  Depending on the length of style and of num_pass that could be a very slow double nested loop.

Rik <rik5>
Project Administrator
Wed 01 Jun 2016 08:39:33 PM UTC, comment #42: 

OK, attached is a version of the mesh patch that removes cruft (and with period at end of summary line).

(file #37346)

Dan Sebald <sebald>
Wed 01 Jun 2016 06:58:52 PM UTC, comment #41: 

I pushed the fix for rotation/view here (http://hg.savannah.gnu.org/hgweb/octave/rev/6c8c18f49eed).

Rik <rik5>
Project Administrator
Wed 01 Jun 2016 06:52:42 PM UTC, comment #40: 

I made a few changes to the mesh cset, mostly using in-place operators because they are faster.

I'm uploading it as mesh.cset.

Could you review your cset again?  I think there is cruft left over from the original implementation.  Specifically,

1235:          len = N_tup * 1;

And then later,

1247:              xrec = len / N_tup;

or

1250:              for kk = 1:N_tup:len

As far as I can see, the for loop is redundant.  It is always executed just once.  And line 1235 could just as well be written 'len = N_tup'.

(file #37340)

Rik <rik5>
Project Administrator
Wed 01 Jun 2016 05:38:45 PM UTC, comment #39: 

OK, please try the attached post-plot view patch.  Try commands like

sombrero
[use mouse to rotate]

demo pcolor
[use mouse to rotate]

In the latter case the angle once rotation begins with the mouse is correct, but because of gnuplot's logic on this the plot size discontinuously jumps to 4/7 the size so that it can accommodate the maximum extent possible by rotation (the distance from one corner of a cube to its associated non-adjacent corner).  I think this is the best behavior that can be achieved for now, but as I say I'm discussing with gnuplot developers right now the finer details about positioning 3D plots.

(file #37337)

Dan Sebald <sebald>
Wed 01 Jun 2016 05:05:09 PM UTC, comment #38: 

Rik, yes I think the second mesh patch is ready.  There's been some discussion on the gnuplot list about making surface lines behave transparent, but I don't think that is a near-term thing.  So, the best is to just stick with drawing individual lines...  The thing that worried me a bit was that the individual lines would mess up the "legend()" somehow, but it doesn't seem to do so.  There is still only one child so only one legend string that can be specified.  BTW, the legend entries for a surface (regardless of toolkit selection) are nothing but a blank space.  Wouldn't it be worth putting maybe a facecolor splotch next to a sample edge line in that space?

The unset view line.  OK, I see now.  pcolor wants to use the map view.  I think there is an easy fix for that:

1) As you suggest, take gnuplot out of 3D map mode when it is set, but rather than use "unset view", use "set view 0,0" (or whatever it is) so that when rotating the map it doesn't make a big jump to a completely different angle.

2) Rather than "view map", just set the angle to 0, 0... i.e., do nothing.  The ramification of that is two things: the projected 2D map view comes out smaller and the annotation for the z axis is all lying on top of one another creating a ball of illegible characters in the lower left corner.  Right now I'm discussing with gnuplot developers the issue of finer 3D layout control using margins--so although going this route makes good sense, gnuplot may be in flux here for a while.  I think I will also raise the issue with them about these perpendicular to viewer axis annotation lying on top of one another...maybe that should just not be displayed of the view comes out orthographic.

Let me redo the previous "set view" patch and attach a new version.

Dan Sebald <sebald>
Wed 01 Jun 2016 03:50:33 PM UTC, comment #37: 

@Dan: The 'unset view' line is there to allow the pcolor plot to be rotated.  pcolor is a 3-D surface, but the view is set to [0, 90] to create a 2-d looking plot.  With the OpenGL toolkits, and I'm pretty sure with Matlab, one can then rotate the plot and have it assume a 3-D form.

Before removing that ability, can you check whether Matlab allows rotation of pcolor plots?  If you have access to Matlab that would be great, but otherwise just ask on the Maintainer's list for a little help.  If we don't have to meet a compatibility goal then I would just eliminate this code.

The cset which made the change was back in 2007 by David Bateman.  To see it, try

hlog -p -r 7271

If we should be keeping this ability then perhaps we should 'unset view' only when the plot is a pcolor one.  We could probably determine this by checking that viewmap was set and that the axis view was [0, 90].

Is the second mesh patch in comment #35 independent of this pcolor issue (aside from performance) so that could be applied now?

Rik <rik5>
Project Administrator
Tue 31 May 2016 12:03:55 AM UTC, comment #36: 

Could we apply the attached patch to get rid of view reset near the end of plotting?  I don't know exactly what that was intended to solve...something about pcolor...so commenting it out will make it easy to locate if doing so breaks something.  Currently, that view reset causes the replot on rotation to jump in a disjointed way to a completely different view.  Try "sombrero" before and after the patch.

I notice that adding a colorbar:

sombrero
colorbar

makes the main plot (sombrero) non-rotatable.  What's happening here is that _gnuplot_draw_now_ is using a multiplot to manually draw the colorbar on its own.  After that, the colorbar is resizable in a 2D sense.  Selecting an area on the sombrero is misleading in that it is really selecting something way in the negative region of the colorbar and comes out white (empty).  There is a gnuplot colorbox that can be configured, so why not that, I don't know.  Another solution would be to plot the colorbar first and then the mainplot, which would leave the main plot mouse active.

(file #37313)

Dan Sebald <sebald>
Sat 28 May 2016 03:17:00 PM UTC, comment #35: 

I'm attaching a new version of the mesh code.  It's simpler and better than the previous version.  The previous version retained the existing code for the 'meshstyle' 'both' case.  The attached version does individual lines in one direction and if 'both' selected then both directions are drawn, still with individual lines.

To test, experiment with the waterfall demo, i.e.,

demo waterfall
[cntrl-c to break from demo]
kids = get(gca, 'children')
set(kids, 'meshstyle', 'row')
set(kids, 'meshstyle', 'column')
set(kids, 'meshstyle', 'both')
set(kids, 'facecolor', 'none')

(file #37297)

Dan Sebald <sebald>
Thu 26 May 2016 08:19:11 PM UTC, comment #34: 

OK, that's good news.  Let's get the axes part cleared up first, and then changing the labels should be straightforward.  I'll have a look again this evening.

Dan Sebald <sebald>
Thu 26 May 2016 05:40:38 PM UTC, comment #33: 

Dan, xlabel, ylabel, and title objects are all type "text". And text objects have 3D positions.

http://www.mathworks.com/help/matlab/ref/text-properties.html

Abandoning gnuplot's xlabel, ylabel, and tilte and opting for labels instead would work, provided the font metrics can be worked out between Octave and Gnuplot. I had considered that in the distant past, but at the time the text object extents were not being updated when using the Gnuplot toolkit. I did a quick check, and discovered that the extents are now being updated.

This is good news, and implies it is relatively simple to let Octave's updaters do all the heavy lifting and just add axes using the property position (no need to worry about the inset) and add the axes labels according to their positions. The result would simplify _gnuplot_draw_axes_ ().

Ben Abbott <bpabbott>
Project Member
Thu 26 May 2016 04:17:57 PM UTC, comment #32: 

Rik, you've a couple demos in the list which indicate a hard crash on, I assume, gnuplot's part.  I'm not seeing any of those.  This may be a GTK bug in a particular version.  I've upgraded to Mint (Ubuntu base) which I think now uses GTK-3 even though it is modified to look more like GTK-2.  Also, I've been consistently running octave in the --no-gui mode so that the Qt plotting freeze doesn't affect matters.

Dan Sebald <sebald>
Thu 26 May 2016 04:12:58 PM UTC, comment #31: 

I suppose when one thinks of x-label, y-label, title it's a relative sort of thing, having to do with automatic placement.  That's gnuplot's perspective, but I suppose it would be nice to have an "at <pos>" feature in gnuplot for "xlabel".

But in some sense, it isn't necessary because if one is going to do manual placement of x-lable, y-lable and title--in this case Octave--the generic "label" can be used for all of those.  Then just leave the xlabel, ylable, zlabel, title empty.  See "help set label" in gnuplot.  In Octave:

>> h = title("This is my title")
h = -55.967
>> get(h, 'type')
ans = text
>> get(h, 'position')
ans =

   5.50000   1.05829   0.50000

>> get(h, 'units')
ans = data

I'm not sure why the "position" is a triple as opposed to a coordinate pair.

Dan Sebald <sebald>
Thu 26 May 2016 03:47:04 PM UTC, comment #30: 

Dan, gnuplot does allow the labels to be "offset", but there is no means to specify the actual positions. Meaning we don't know where they are to be placed and thus, can make adjustments without user interaction. Perhaps we could add an additional property to the xlabel, ylabel, and title objects to allow them to be offset? I don't know if that is possible since they are essentially text objects and likely can't have additional properties.

Ben Abbott <bpabbott>
Project Member
Thu 26 May 2016 02:59:13 PM UTC, comment #29: 

Ben, I believe gnuplot does have a means to control the placement of labels.  My perspective on the multiple and sometimes inconsistent terminal behavior is that I really don't mind if the output format isn't exactly WYSIWYG so long as there is a way to tweak the plot when it comes to generating a publication-quality figure.  Anyway, think about this position/outerposition/actual_position code for a couple days and see if anything comes back to mind that is obviously wrong.  My fear would be I too hastily make a big change that runs counter to the positioning paradigm and break some subtle thing elsewhere that will be equally difficult to debug once it is discovered.

One thing I'm wondering at the moment is why the axes position, i.e., the actual coordinates for the axes object, are telling us this is "outerposition" rather than just "position".  Or, maybe that is what the _actual_position_ intention was.  I.e., if the user specifies placement with respect to outerposition, _actual_position_ needs to translate that into the location of the "actual axes position".

Dan Sebald <sebald>
Thu 26 May 2016 02:43:17 PM UTC, comment #28: 

OK, attached is a fix for 'meshstyle' property.  The concept is that given an M x N grid of mesh data, create M (or N) meshes of 2 x N (or M) points in which the data is repeated.  If anyone can think of a better way of generating the data, but I don't think this extra indenting and testing obfuscates the original algorithm too much.

(file #37279)

Dan Sebald <sebald>
Thu 26 May 2016 01:48:48 PM UTC, comment #27: 

@Dan,

My recollection of what was done for gnuplot is coming back to me bit by bit.

When the activepositionproperty = "position", Octave controls the axis position. When it is equal to "outerposition" we let gnuplot handle things, since we don't have control over the positions of the axes labels, and different terminals actually place the labels differently.

When I was working on this I recall it wasn't possible to always have gnuplot behave in a Matlab compatible manner. And when OpenGL toolkits became available, we started being more flexible letting gnuplot do things its way when compatibility was difficult/impossible.

I don't recall how accurate actual_axis_position is. I'll need to take a closer look

Ben Abbott <bpabbott>
Project Member
Thu 26 May 2016 01:48:15 PM UTC, comment #26: 

Post it here.  We'll continute to work through issues here until this bug report gets too long and cluttered.  At that point we can open up a new report on any particular small differences that remain.

Rik <rik5>
Project Administrator
Thu 26 May 2016 07:33:17 AM UTC, comment #25: 

I have a fix for the waterfall.m demo to make gnuplot toolkit result look like Qt toolkit result.  Should I post it here?  New bug report?  New patch report?

Dan Sebald <sebald>
Thu 26 May 2016 03:24:01 AM UTC, comment #24: 

To follow up on what I described in the last post, I'm attaching a screenshot of the apparently working Qt toolkit output

Screenshot from 2016-05-25 21:43:10-ANNOTATED.png

in which I imported the figure into GIMP and added some notes where I've compute the number of pixels from GIMP's position indicator.

Given this:

>> kids = get(gcf, 'children')
kids =

  -454.67
  -549.39
  -644.87
  -656.61

>> get(kids(4),'position')
ans =

   0.13000   0.11000   0.77500   0.79758

>> get(kids(4),'units')
ans = normalized

I can believe that the 0.13 represents the left edge of the blue box.  That is (in pixels) 72/561 = 0.12834.  Alright, good.  But on the right edge I'm left wondering because (561-55)/561 = 0.90196, but Octave is indicating the position of the axes is 0.77500....   OH!  Wait, the position is lower right corner = (pos(1), pos(2)) and width is 0.77500 and height is 0.79758.  Let me adjust that in my debug code.

OK, attached is also a new diff file for debugging purposes and this one correctly positions the axes in alignment with the blue box.  So that is a step in the right direction, but the diff I provided is by no means correct as there is still the axes labels not falling in the locations expected, resize plot doesn't work quite right either.

Well, Ben can you provide some insight on how to go about fixing this?

file #37269)

Dan Sebald <sebald>
Thu 26 May 2016 02:32:45 AM UTC, comment #23: 

I was wrong about the previous changeset for axes visibility.  It doesn't break the Qt behavior.

Well, to move this along I'm attaching a debugging type of patch where I've changed a few lines of code and display some info to try to make sense of what is being called and when (debug_axes_pos_djs2016may25.diff).  Rather than leave margins up to gnuplot, I've set them to the axes position... that may not be the correct thing to do, but it is illustrating the behavior.  This outputs for me:

pos =

   0   0   1   1

ans = axes
ans =

   0.13000   0.11000   0.77500   0.79714

ans = HI 1
ans = HI 11
pos =

   0   0   1   1

ans = axes
ans =

   0   0   1   1

ans = HI 1
ans = HI 2
ans = HI 3
ans = HI 4

OK, so the first half of this output is the plot of the data (linear curve) and that is the one having a setting of "outerposition" (prints out HI 11).  Ben could you explain a couple things about what we're seeing?

1) What is pos (i.e., _actual_axis_position_()) supposed to represent?  It has it's actual position at [0 0 1 1].  How could that be an axes position?

2) The axes position property is

>> get(kids(4),'position')
ans =

   0.13000   0.11000   0.77500   0.79714

but I don't see what that could possibly represent on any of the reference frames.  Any idea what that is?

Just looking at the scant evidence, I would guess that _actual_axes_position_() isn't telling us the correct answer for the data drawing pass through the loop.

(file #37267)

Dan Sebald <sebald>
Thu 26 May 2016 01:50:01 AM UTC, comment #22: 

gnuplot does have a mode where aspect ratio is maintained, but to go into that mode means that gnuplot will adjust white space on the edges of the screen and I suspect that will throw off Octave's screen coordinate reference system.

Dan Sebald <sebald>
Thu 26 May 2016 01:45:10 AM UTC, comment #21: 

I'll take a look at that squashed elliptoid next.  At the moment I've been looking at the axes position issue that I see several times in the demos.  In particular

scripts/plot/appearance/annotation.m example 2:

This is the demo which plots a red, green and blue dashed box illustrating where the boundary for the canvas, axes and title area or...or something like that.

Ben just wrote something about margins and that's the issue in this case here.  We should probably get this straight first.  And the last patch we applied may have altered this plot for Qt toolkit in an undesirable way.  Let me try to characterize this one a bit and write back.  I think this will go to Ben eventually because he wrote the _actual_axis_position_() script and know that best.

All I can say right now is that the position of the axis is not coming from Octave, but I thought some time ago that Octave had taken control of that layout.  That is, this code in _gnuplot_draw_axes_:

  else ## activepositionproperty == outerposition
    fprintf (plot_stream, "unset tmargin;\n");
    fprintf (plot_stream, "unset bmargin;\n");
    fprintf (plot_stream, "unset lmargin;\n");
    fprintf (plot_stream, "unset rmargin;\n");

is what is executed, leaving the axes layout up to gnuplot.  Instead, it should be going the route of set the margins to specific values in the screen coordinates.  I'll write more later...

Dan Sebald <sebald>
Thu 26 May 2016 01:33:17 AM UTC, comment #20: 

The problem with vertical placement of the axis titles for 3D plots (demo ezsurf 3) is triggered by setting the margins. The problem can be compensated for by offsetting the title, but the calculate needed is complicated and relies upon the size of the figure window which Octave cannot know (since it maybe modified by the user/mouse).

The improper aspect ratio of 3d plots is likely due to both the setting of the margins and to the lines below (from _gnuplot_draw_axes_.m)

  90         ## 3D plots need to be sized down to fit in the window.
  91         x = 1.0 ./ sqrt ([2, 2.5]);

This also relies upon the size of the figure window, which Octave cannot know.

Ben Abbott <bpabbott>
Project Member
Wed 25 May 2016 04:48:16 PM UTC, comment #19: 

@Dan: I applied your patch for "visible" attribute on axes here (http://hg.savannah.gnu.org/hgweb/octave/rev/6cf6bc451eeb).  I changed the commit message just slightly.  First, to include the bug number that the patch was written for, second, we don't need to be verbose and repeat which function was modified if it is an m-file and the function is the same as the name of the m-file.

The next demo which looks interesting is isosurface.  There are two things I see.  First, the length of the Z-axis onscreen is different from the X and Y axes.  This creates a squashed ellipsoid, rather than a sphere.

demo isosurface
pbaspect
=> [5 4 4]

This is rather odd, because this says the x-axis should be 1.25X the Y or Z axes.  Instead, it looks more like [4 4 3] because the Z-axis from -1 to +1 takes up about the same as 1.5 X-axis units.

The second issue is the box.  In the OpenGL toolkits, when you turn off the box you turn off everything but the X, Y, and Z axes (3 lines).  In gnuplot, only the front lines are turned off.  The perspective axes lines "behind" the object are still there.

Rik <rik5>
Project Administrator
Wed 25 May 2016 04:25:46 PM UTC, comment #18: 

Gnuplot is correct.  Neither Matlab nor the OpenGL toolkits support an axislocation of 'zero'.  Since we control the OpenGL renderer we should be able to add support for this.  It has been on my list for several years, but it isn't that important so I haven't done it.

Rik <rik5>
Project Administrator
Wed 25 May 2016 03:18:30 PM UTC, comment #17: 

Matlab only supports "top" or "bottom". The OpenGL behavior looks to be the same as "left", and "bottom". So, I'd say that Gnuplot is correct.

Ben Abbott <bpabbott>
Project Member
Wed 25 May 2016 02:56:43 PM UTC, comment #16: 

Ben, the patch from last night is generally correct, but I'm attaching a slight tweak of that gets ride of the border (but not necessarily the tics) no matter what since that seems to be handled by do_border_2d().

Before applying this, take a look at the demo:

    scripts/plot/appearance/axis.m example 9:

The title says "xaxislocation = zero, yaxislocation = zero".  Is gnuplot toolkit correct?  Or is qt toolkit correct?

(file #37261)

Dan Sebald <sebald>
Wed 25 May 2016 11:35:05 AM UTC, comment #15: 

Dan's patches work for me. I have some comments on some of the remaining problems but am in a rush, so will need to return to this later.

Ben Abbott <bpabbott>
Project Member
Wed 25 May 2016 07:19:48 AM UTC, comment #14: 

polar : #1 : a rectangular box is drawn around the entire plot

I haven't tested this thoroughly, but give the attached patch a try.  Solving this example seems to solve a lot of other demo problems regarding extra axes and borders.

(file #37257)

Dan Sebald <sebald>
Wed 25 May 2016 05:51:08 AM UTC, comment #13: 

The axes are not individually controllable.  If the axes object has the visibility property set to 'off' then everything associated with it should disappear.  That's why the 'box = on' doesn't matter for the Qt toolkit because the entire axes has been shut off.

Rik <rik5>
Project Administrator
Wed 25 May 2016 05:43:43 AM UTC, comment #12: 

It looks to me that the box is being turned off, but left behind is the axes.  The axes aren't noticeable when the box is on.  They shouldn't be there.  Is this

    visible = off

the property that should control the presence of those axes?  They are not individually controlled are they?  I.e., either both visible or both not visible?

Also, when I run this 'demo polar 1' in Qt graphics toolkit I see no box.  But the axes object has "box = on", so I'm assuming Qt graphics toolkit is missing something.

Dan Sebald <sebald>
Wed 25 May 2016 05:40:26 AM UTC, comment #11: 

More musings.

The real problem seems to be that setting the 'visible' property on the axes objet to 'off' removes ticks and labels, but does not remove the actual lines of the axis.

Sample code

plot (1:10)
set (gca, 'visible', 'off')

Rik <rik5>
Project Administrator
Wed 25 May 2016 05:34:17 AM UTC, comment #10: 

Just another thought, it may be that there is a white patch which is supposed to hide the axes.  I just did

demo polar 1
box off
set (gca, 'yaxislocation', 'zero')
set (gca, 'xaxislocation', 'zero')

and then I have a good-looking plot.

Rik <rik5>
Project Administrator
Wed 25 May 2016 05:29:29 AM UTC, comment #9: 

@Dan: I applied your patch to fix up meshcolor/facecolor here (http://hg.savannah.gnu.org/hgweb/octave/rev/45871845a93c).

I find that it has also made my plotting with gnuplot more stable.  Previously I would get "broken pipes" or some other fault pretty frequently.

I think the next easy difference is to figure out why 'box off' isn't working completely.

For example,

demo polar 1
box off

Rik <rik5>
Project Administrator
Tue 24 May 2016 01:12:05 AM UTC, comment #8: 

ezmeshc demo:  Well, the issue is pretty simple.  This ezmeshc demo draws a couple dozen patches after it does the surface/edge construction.  The patches have a facecolor of "none".  (Why it is doing this, I don't know.)  So, there is a conflict of multiple graphical objects wanting to set the global hidden_removal property (i.e., whether "set hidden3d front nooffset" is applied) differently.

Also, the "hopt" in the surface object has no affect on gnuplot's "with lines".  I.e., "with lines nohidden3d" never actually disabled hidden3d for lines, contrary to my understanding.  I went back to the gnuplot code to verify it has that internal logic, i.e.,

            if (this_plot->plot_style == LINES) {
                this_plot->opt_out_of_hidden3d = FALSE;
            }

So, given that fact, rather than make the default behavior "set hidden3d", in the attached patch I make the default behavior "unset hidden3d" and the rule is that the surface and patch can set "set hidden3d", but they can't remove it.  That is, normally there is no hidden3d behavior, but once it is set it stays on.  Without the fine control of individually controlling line removal behavior, this seems like the best that can be done, and it seems consistent with all the demos

rundemos appearance
rundemos draw
rundemos util

I'm sure it wouldn't take too much to create a plot that causes problems, e.g., put two surface on the plots--one with hidden behavior and one with facecolor "none".  I wish gnuplot were a bit more flexible this way (e.g., handle hidden removal in groups, true hidden surfaces, etc.), but it would be quite a while before that arrives.

(file #37243)

Dan Sebald <sebald>
Mon 23 May 2016 03:28:27 PM UTC, comment #7: 

@Panxto: I reverted to cset 21542 and tried to run the annotation demo under gnuplot.  The first demo runs, but there is no visible figure.  The second demo then issues a 'broken pipe' warning and communication with gnuplot is lost and I have to Ctrl+C out of Octave.  It seems there is still something badly wrong with how the gnuplot backend is handling some of the instructions given it by Octave.

Rik <rik5>
Project Administrator
Mon 23 May 2016 10:31:59 AM UTC, comment #6: 

As for the annotation demo #1, it doesn't hang with gnuplot 4.6, it only takes very much time. Actually all annotation demos are affected and I think this is due to this cset:

changeset:   21543:4f0f9f029d12
user:        Lachlan Andrew <lachlanbis@gmail.com>
date:        Mon Feb 22 13:18:02 2016 +1100
summary:     Draw updates to GUI at end of GUI callback function (bug #47216)

Annotations make extensive use of listener .m callbacks, even at initialization (this could be changed but will probably lead to duplicate code), and each callback execution triggers a redraw of the whole figure. Considering that annotation demos usually draw at the very least 3 annotation objects, this leads to many unnecessary redraws.

Pantxo Diribarne <pantxo>
Project Member
Mon 23 May 2016 06:27:46 AM UTC, comment #5: 

Ah, OK.  The mesh is behind the surface when it should always be in front.  I looked at the gnuplot code useing "drawnow()" and there is a line "unset hidden3d", but nothing after it.  The setting should eventually be "set hidden3d front" so that all other items affected by hidden3d sorting are drawn after the surface.  Should be an easy changeset, but it may take a day or two to get back to this.

Dan Sebald <sebald>
Mon 23 May 2016 05:01:38 AM UTC, comment #4: 

The facecolor setting is correct.  The face should be white, but the edges should be drawn.  The edgecolor in this case is 'flat' and should take the color from the 'cdata' property.

To test, you can do something like

demo ezmeshc
h = get (gca, 'children')(2);
set (h, 'edgecolor', 'r')

I tried this and it set the outer edge to be red, but the mesh is still not visible.  If I set the facecolor 'none' then the mesh is visible.

set (h, 'facecolor', 'none')

Rik <rik5>
Project Administrator
Mon 23 May 2016 04:47:46 AM UTC, comment #3: 

Rik, let's start with

ezmeshc : #1 : mesh is completely white

because that is the one that stood out to me when I looked hastily through the demos.

First, just to get my thinking straight, I'm looking at the figure/children properties.  For that ezmeshc example, I'm seeing one child of the figure and that child has two children of its own.  One of those children is a "surface", and looking at the properties for that surface, I'm seeing:

    edgealpha =  1
    edgecolor = flat
    edgelighting = none
    erasemode = normal
    facealpha =  1
    facecolor =

       1   1   1

    facelighting = none
    facenormals = [](0x0)
    facenormalsmode = auto

and those are the properties we were just working on with the prior gnuplot patch.  The above properties are independent of the toolkit, however, so assume they are the desired properties.  The facecolor is 1 1 1, and as I understood this from the previous gnuplot changeset is that we should see a white surface, which is what the gnuplot example is doing.

Is it possible that the qt toolkit is missing the surface in this case?  Why is the ezmechc example setting facecolor to 1 1 1 instead of 'none'?  Am I overlooking something (there are a lot of properties I'm sure I'm unfamiliar with)?

Dan Sebald <sebald>
Mon 23 May 2016 12:19:14 AM UTC, comment #2: 

The issue with the Plot_comparison page on the wiki is that it has not been run in a long time and some of the issues are fixed or out of date.  Also, that page is generally concerned about differences between Octave and Matlab.  This report is about differences within Octave from the exact same code, but a different toolkit.

Rik <rik5>
Project Administrator
Sun 22 May 2016 09:48:05 AM UTC, comment #1: 

There is also http://wiki.octave.org/Plot_comparison
Should we merge the problems here to the wiki page or fron the wiki back or leave them separates?

Anonymous
Sun 22 May 2016 05:31:31 AM UTC, original submission:  

I ran many of the graphics demos with the qt and gnuplot toolkits.  I recorded the differences I found below.  The tests were done with gnuplot 5.0.1 and the development tip 21761:ff2b9f7069c5.  The format is "FUNCTION : DEMO # : PROBLEM"

ezmeshc : #1 : mesh is completely white
polar : #1 : a rectangular box is drawn around the entire plot
ezsurf : #3 : position of titles is within the plot, rather than above it.
ezsurfc : #1 : shading is different.  It is faceted for OpenGl, and possibly 'flat' for gnuplot.
isosurface : #1 : squashed perspective (not axis equal).  plot box is still on
meshc : #1 : mesh is compltely white
patch : #7 : 'interp' shading is not working
plotyy : #1 : causes hard failure.
Gdk:ERROR:/build/gtk+2.0-gl_hAC/gtk+2.0-2.24.28/gdk/gdkregion-generic.c:337:miSetExtents: assertion failed: (pExtents->y1 < pExtents->y2)
annotation : #1 : hangs Octave

It seems several are related to the box command which does not remove all axis lines in gnuplot as it does with OpenGL.

Rik <rik5>
Project Administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #37340:  mesh.cset added by rik5 (5KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by avinoam (Posted a comment)
  • -email is unavailable- added by bpabbott (Posted a comment)
  • -email is unavailable- added by pantxo (Posted a comment)
  • -email is unavailable- added by sebald (Posted a comment)
  • -email is unavailable- added by rik5 (Submitted the item)
  • -email is unavailable- added by rik5
  • -email is unavailable- added by rik5
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

     

     

    Follow 25 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-10-02 rik5 StatusIn Progress => Fixed
        Open/ClosedOpen => Closed
    2016-10-02 sebald Attached File- => Added octave-gnuplot_no_rgb_transform_bug47974-djs2016oct01.patch, #38640
    2016-09-30 sebald Attached File- => Added octave-gnuplot_markeredgecolor_bug47974-djs2016sep30.patch, #38633
    2016-09-22 sebald Attached File- => Added octave-gnuplot_linestyle_bug47974-djs2016sep22.patch, #38589
    2016-09-19 sebald Attached File- => Added octave-gnuplot_linestyle_bug47974-djs2016sep19.patch, #38557
    2016-06-20 sebald Attached File- => Added octave-gnuplot_dot_point_type-djs2016jun20.patch, #37528
    2016-06-09 sebald Attached File- => Added octave-gnuplot_do_text-djs2016jun09.patch, #37437
    2016-06-07 sebald Attached File- => Added octave-gnuplot_border_and_tick_text-djs2016jun06.patch, #37415
    2016-06-03 sebald Attached File- => Added octave-gnuplot_title_placement-djs2016jun03.patch, #37383
    2016-06-03 sebald Attached File- => Added octave-gnuplot_border_and_tick_text-djs2016jun02.patch, #37367
    2016-06-02 sebald Attached File- => Added octave-gnuplot_aspect_ratio-djs2016jun02.patch, #37358
    2016-06-02 sebald Attached File- => Added octave-gnuplot_patch_color_triad-djs2016jun02.patch, #37357
    2016-06-02 sebald Attached File- => Added .octave-assert_vector_tolerance-2013aug05.patch.swp, #37355
    2016-06-01 sebald Attached File- => Added octave-gnuplot_meshstyle_restore_variable-djs2016jun01.patch, #37347
    2016-06-01 sebald Attached File- => Added octave-gnuplot_meshstyle-djs2016jun01.patch, #37346
    2016-06-01 rik5 Attached File- => Added mesh.cset, #37340
    2016-06-01 sebald Attached File- => Added octave-gnuplot_no_view_reset-djs2016jun01.patch, #37337
    2016-05-31 sebald Attached File- => Added octave-gnuplot_no_view_reset-djs2016may30.patch, #37313
    2016-05-28 sebald Attached File- => Added octave-gnuplot_meshstyle-djs2016may28.patch, #37297
    2016-05-26 sebald Attached File- => Added octave-gnuplot_meshstyle-djs2016may26.patch, #37279
    2016-05-26 sebald Attached File- => Added Screenshot from 2016-05-25 21:43:10-ANNOTATED.png, #37268
        Attached File- => Added debug_axes_pos_djs2016may26.diff, #37269
    2016-05-26 sebald Attached File- => Added debug_axes_pos_djs2016may25.diff, #37267
    2016-05-25 sebald Attached File- => Added octave-gnuplot_axes_visibility-djs2016may25-v2.patch, #37261

    Back to the top


    Powered by Savane 3.5