I wonder how the Mathworks implemented switching between hardware and software rendering on the run (on Windows):
https://de.mathworks.com/help/matlab/ref/opengl.html

Can we unload one dynamic library and load a different one that provides the same symbols?

Rik: Just a minor point about Matlab behavior. Matlab
switches to software OpenGL if it finds that OpenGL
is not available, such as for remote plotting. Someday,
similar behavior for Octave may be a good choice in addition
to the user option. The current choice is right for 4.2
at least.

The minor problem reported by Michael Godfrey seems to be an issue whenever the graphics toolkit is not qt.  Either gnuplot, or fltk, will produce the warning.

./run-octave -f --no-gui
graphics_toolkit fltk
__opengl_info__
warning: __opengl_info__: can not obtain OpenGL information
warning: called from
    __opengl_info__ at line 64 column 5

It seems that FLTK needs to have an object actually drawn before the OpenGL fields get populated in properties.  I pushed a cset here (http://hg.savannah.gnu.org/hgweb/octave/rev/fddc5604d1fa) which draws an axes object and then calls drawnow(), rather than waitfor with a 1 second delay, in order to force the graphics system to populate the fields.

@Michael, fyi:

octave:1> graphics_toolkit gnuplot
octave:2> _opengl_info_
warning: _opengl_info_: can not obtain OpenGL information
warning: called from
    _opengl_info_ at line 64 column 5

Dmitri.

Michael:  That's strange, it works for me.  The following lines in the function attempt to create a figure if none already exists:

  if (isempty (info))
    h = figure ("position", [0,0,1,1], "toolbar", "none", "menubar", "none");
    waitfor (h, "timeout", 1);
    info = fig_gl_info (h);
    close (h);
  endif

I'm not sure what is preventing this from working for you.

John D:  I checked in a modified version of your changeset here:

http://hg.savannah.gnu.org/hgweb/octave/rev/8a456af24e6b

Since I expect this function to mostly be used for debugging purposes, I renamed it to _opengl_info_.  I also used nargout to determine whether to return a struct or print the info.  It also now displays the list of extensions when printing the info.

@Dmitri, comment #61:
I have run my test script again on the machine that originally produced faulty files, this time using Octave 4.0.3 from ftp://ftp.gnu.org/gnu/octave/windows/ . Lines, axes and labels are fine in the created files, apart from bug #31596 and bug #48387.

Looking again at some of the entries, this looks to be a different issue in which the EPS file is generated but internally is incorrect, sorry.  The one I was referring to is the crash when there is no GUI active:

  GEN      doc/interpreter/voronoi.eps
panic: Segmentation fault -- stopping myself...

This has been a problem for ages for me, and it's quite annoying.

Here's a new wrinkle.  Some kind of stamp file in the source tree that must have been placed there from the build process:

make[2]: Entering directory `/home/sebald/matlab/octave/test_build'
HG-ID is unchanged
make[3]: Entering directory `/home/sebald/matlab/octave/test_build'
make[3]: Leaving directory `/home/sebald/matlab/octave/test_build'
cp: cannot create regular file ‘../octave/doc/interpreter/stamp-vti’: Permission

The permission issue is from the fact that I typically build as su/root in some directory that is not under backup because I don't want the huge bundle of object files saved to a backup drive.  So I thought I would try building from the account where I keep the source code and make modifications for changesets, but then got the error.

After deleting that stamp file, compilation eventually completes, and then:

  MAKEINFO ../octave/doc/interpreter/octave.info
HG-ID is unchanged
make[3]: Entering directory `/home/sebald/matlab/octave/test_build'
make[3]: Leaving directory `/home/sebald/matlab/octave/test_build'
cp: cannot create regular file ‘../octave/doc/liboctave/stamp-1’: Permission denied
make[2]: *** [../octave/doc/liboctave/stamp-1] Error 1
make[2]: Leaving directory `/home/sebald/matlab/octave/test_build'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/sebald/matlab/octave/test_build'
make: *** [all] Error 2

OK, so that's another stamp file left over from a root build.  I delete that and eventually:

Installing test/.gdbinit from version at ../octave/etc/gdbinit
Installing .gdbinit from version at ../octave/etc/gdbinit
  GEN      doc/interpreter/voronoi.eps
panic: Segmentation fault -- stopping myself...
attempting to save variables to 'octave-workspace'...
save to 'octave-workspace' complete
octave exited with signal 11
  GEN      doc/interpreter/triplot.eps
panic: Segmentation fault -- stopping myself...
attempting to save variables to 'octave-workspace'...
save to 'octave-workspace' complete
octave exited with signal 11
  GEN      doc/interpreter/griddata.eps
panic: Segmentation fault -- stopping myself...
attempting to save variables to 'octave-workspace'...
save to 'octave-workspace' complete
octave exited with signal 11
  GEN      doc/interpreter/convhull.eps
panic: Segmentation fault -- stopping myself...
attempting to save variables to 'octave-workspace'...
save to 'octave-workspace' complete
octave exited with signal 11
  GEN      doc/interpreter/delaunay.eps
panic: Segmentation fault -- stopping myself...
attempting to save variables to 'octave-workspace'...
save to 'octave-workspace' complete
octave exited with signal 11
  GEN      doc/interpreter/inpolygon.eps
panic: Segmentation fault -- stopping myself...
attempting to save variables to 'octave-workspace'...
save to 'octave-workspace' complete
octave exited with signal 11
  GEN      doc/interpreter/interpft.eps
panic: Segmentation fault -- stopping myself...
attempting to save variables to 'octave-workspace'...
save to 'octave-workspace' complete
octave exited with signal 11
  GEN      doc/interpreter/interpn.eps
panic: Segmentation fault -- stopping myself...
attempting to save variables to 'octave-workspace'...
save to 'octave-workspace' complete
octave exited with signal 11
  GEN      doc/interpreter/interpderiv1.eps
panic: Segmentation fault -- stopping myself...
attempting to save variables to 'octave-workspace'...
save to 'octave-workspace' complete
octave exited with signal 11
  GEN      doc/interpreter/interpderiv2.eps
panic: Segmentation fault -- stopping myself...
attempting to save variables to 'octave-workspace'...
save to 'octave-workspace' complete
octave exited with signal 11
  GEN      doc/interpreter/plot.eps
panic: Segmentation fault -- stopping myself...
attempting to save variables to 'octave-workspace'...
save to 'octave-workspace' complete
octave exited with signal 11
  GEN      doc/interpreter/hist.eps
panic: Segmentation fault -- stopping myself...
attempting to save variables to 'octave-workspace'...
save to 'octave-workspace' complete
octave exited with signal 11
  GEN      doc/interpreter/errorbar.eps
panic: Segmentation fault -- stopping myself...
attempting to save variables to 'octave-workspace'...
save to 'octave-workspace' complete
octave exited with signal 11
  GEN      doc/interpreter/polar.eps
panic: Segmentation fault -- stopping myself...
attempting to save variables to 'octave-workspace'...
save to 'octave-workspace' complete
octave exited with signal 11
  GEN      doc/interpreter/mesh.eps
panic: Segmentation fault -- stopping myself...
attempting to save variables to 'octave-workspace'...
save to 'octave-workspace' complete
octave exited with signal 11
  GEN      doc/interpreter/plot3.eps
panic: Segmentation fault -- stopping myself...
attempting to save variables to 'octave-workspace'...
save to 'octave-workspace' complete
octave exited with signal 11
  GEN      doc/interpreter/extended.eps
panic: Segmentation fault -- stopping myself...
attempting to save variables to 'octave-workspace'...
save to 'octave-workspace' complete
octave exited with signal 11
  GEN      doc/interpreter/gplot.eps
panic: Segmentation fault -- stopping myself...
attempting to save variables to 'octave-workspace'...
save to 'octave-workspace' complete
octave exited with signal 11
  GEN      doc/interpreter/grid.eps
panic: Segmentation fault -- stopping myself...
attempting to save variables to 'octave-workspace'...
save to 'octave-workspace' complete
octave exited with signal 11
  GEN      doc/interpreter/spmatrix.eps
panic: Segmentation fault -- stopping myself...
attempting to save variables to 'octave-workspace'...
save to 'octave-workspace' complete
octave exited with signal 11
  GEN      doc/interpreter/spchol.eps
panic: Segmentation fault -- stopping myself...
attempting to save variables to 'octave-workspace'...
save to 'octave-workspace' complete
octave exited with signal 11
  GEN      doc/interpreter/spcholperm.eps
panic: Segmentation fault -- stopping myself...
attempting to save variables to 'octave-workspace'...
save to 'octave-workspace' complete
octave exited with signal 11
  GEN      doc/interpreter/splinefit1.eps
panic: Segmentation fault -- stopping myself...
attempting to save variables to 'octave-workspace'...
save to 'octave-workspace' complete
octave exited with signal 11
  GEN      doc/interpreter/splinefit2.eps
panic: Segmentation fault -- stopping myself...
attempting to save variables to 'octave-workspace'...
save to 'octave-workspace' complete
octave exited with signal 11
  GEN      doc/interpreter/splinefit3.eps
panic: Segmentation fault -- stopping myself...
attempting to save variables to 'octave-workspace'...
save to 'octave-workspace' complete
octave exited with signal 11
  GEN      doc/interpreter/splinefit4.eps
panic: Segmentation fault -- stopping myself...
attempting to save variables to 'octave-workspace'...
save to 'octave-workspace' complete
octave exited with signal 11
  GEN      doc/interpreter/splinefit6.eps
panic: Segmentation fault -- stopping myself...
attempting to save variables to 'octave-workspace'...
save to 'octave-workspace' complete
octave exited with signal 11
  TEXI2DVI doc/interpreter/octave.dvi
/usr/bin/texi2dvi: etex exited with bad status, quitting.
make[2]: *** [doc/interpreter/octave.dvi] Error 1
make[2]: Leaving directory `/home/sebald/matlab/octave/test_build'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/sebald/matlab/octave/test_build'
make: *** [all] Error 2

So, "make install" won't complete.

If I were to make a change and recompile, the <buildtree>/run-octave executable works but there is this slow process of trying to build all these doc files again.  Generally, re-compilation has become so slow that it is difficult to tackle significant C++ code mods, for me anyway.  Tweaking a line here or there is do-able, but other than that, one spends most of the time waiting for compilation to complete.  About a year ago it used to be the case that once compilation got to the GUI subdirectory the compiler would speed through those files--so making C++ code changes in the GUI wasn't too bad.  But now too the GUI files are compiled at a crawl.  Is there anything that can be done to speed compilation as well?

Michael, I agree entirely with your last paragraph.

Could someone with authority please clarify exactly what the blocking issue is, and whether it is still a blocker or if that is just left over from before the patch of comment #30.

Do we still have printing issue? The original report is more than a year old and its for 4.0.0rc.
Figs in doc are now built with qt backend and apparently it is going ok for majority of builders.

Dmitri.
--

It does not look like an octave problem.
If I ssh from i7 (HD3000 graphics) to amd (radeon graphics), OpenGL program would not work (even glxinfo just returns
name of dislay: localhost:10.0
and then hangs -- Ctr-C returns to prompt).

Going the other way (ssh from amd to i7 works.
running e.g. sombrero (with qt graphics) results in

libGL error: failed to authenticate magic 1
libGL error: failed to load driver: r600

error messages on the octave console, but sombrero
diplays just fine.
The same errors I get if I run glxgears...

Dmitri.
--

Probably do need something like the opengl command to find out what is going wrong on failing machines.  It should probably be a separate Feature Request.  It may also need to include OSMESA information.

Retagging release from 4.0.0-rc3 to 4.0.0.

I assume that this is the surviving bug report and that
44915 will be merged into it.

from the testing that I have done:

1. gnuplot still "works." I do not find it adequate,  but
   it does some things OK.  And, it appears to be less
   subject to system-dependence.

2. For Fedora systems, using the environment variable
   which prevents hangs and visible off fpr print, works
   perfectly well.

3. qt has problems -- worse when used through ssh.

Matlab seems to have been struggling with similar problems.

So, for the 4.0 release, would it make sense to:

1. Set default graphics_toolkit('fltk')

2. Recommend trying qt or reverting to gnuplot if
   necessary.

More testing of fltk on other systems will be needed to
validate this approach. However, in any case, it appears
that quite a lot of work will be needed to get qt working
as well as fltk.

Of course, this is a "view from Fedora!"

Michael:  Sorry, I missed your comment (#50 (!)).

Are you actually building with qt5?  I thought we bypassed that even if it was present on the build system and were still using qt4.

Yes, the --no-gui option still uses the octave-gui binary that is linked with Qt but it just doesn't start the GUI.

So on some systems the Qt graphics window hangs when connecting with ssh but we have no clue why or how to avoid that problem?  But the fltk widget works?

Ugh.  This is really becoming annoying.  I have little to no clue how to fix these problems.

Yes, that is the revision ID of my change, so if you are using that, you have it.

I did a little digging and it looks like the problem is this, or something similar:

https://bugreports.qt.io/browse/QTBUG-37878

I found it crashing inside the same Qt function anyway...

John:  ssh still hangs. But, since this appears to have been
true for some time I would still say that it should not be
a blocker for 4.0.

But, it and related print problems should be given serious
attention after the release.

I do think that relying on Opengl is risky. Maybe this
should be made optional. My system with Intel HD 6000
graphics shows that the software, at least for Fedora,
lags behind the hardware availability.

This looks good enough so that this bug should no
longer be a blocker.

Getting all the cases straight and fixing the various
other problems with plotting (remote access, hardware
use, etc) will take quite a while.

From my standpoint (mainly Fedora...) the current rc4+John's patch
is much better than previous systems.

Identifying the driver/version for the systems that are failing would help.  For Linux, glxinfo appears to have the GL_ parameters.

The source tree for the various drivers is available on line in git, so this bug could be searched there.

http://cgit.freedesktop.org/mesa/mesa/

It's possible to build all the drivers and Mesa locally to find out if the latest drivers fix the problem (or help debug the driver).  This takes some time, not too bad but also not something for the impatient.  It's a lot of this sort of compiling:

[compiling resources so that they look to a different package configuration than the OS bundles default package directory...the install will place the library files and drivers in the local folder, not system folder]

git clone <repository>
PKG_CONFIG_PATH=/home/local/lib/pkgconfig:/usr/local/lib64:$PKG_CONFIG_PATH cmake .
make
make install

and

[Run the application so that it loads drivers from the new library path]

LD_LIBRARY_PATH=/home/local/lib:/usr/local/lib64 <path>/run-octave

The end result is a bunch of library files in local/lib, and a half dozen drivers in local/lib/dri.  Windows might be more challenging.

Won't the change in comment #30 only apply to Qt-based plotting?  If it is correct that the hardware driver for OpenGL that is causing the problem then FLTK should still produce faulty output.

This could, at least, help confirm that the issue is the HW driver.  Steps to take are running the altered code from jwe in comment #30 on a failing system and then printing the failing figure twice using the two toolkits qt and fltk.  The qt toolkit should pass and the FLTK toolkit should fail.

Assuming that is correct, it would be nice to have something like mesa installed so that we could have both toolkits switch over to software rendering if there was a problem.  It certainly would also be good to have a configuration option for this at run-time.  It's not like we have gotten a lot of reports about this so HW based rendering is probably okay on > 75% of machines.  The majority shouldn't be held hostage to the minority in this case.

I now have a report that the change I posted in comment #30 fixes (or at least avoids) the problem.  So I suspect some kind of driver or hardware bug, which would also seem to explain why the bug appears on some systems and not others.

When looking at printing plot (1:10), I saw the following differences in the line.  On the bad system, it would start at (2,2) or (3,3) and on my virtualbox VM, it would start at (1,1) as expected.  I've trimmed the output to just focus on the line segment, not the axes.

The following lines correspond to the endpoints of the 9 line segments from 1:10 (RGB value is 0 0 1, so that's the blue line).  These are the values that gl2ps is getting back from OpenGL.  Note that the first two segments are duplicate points, so they are don't end up being line segments.  This explains why part of the line is missing.

The bad system:

   LINE: 119.519989 82.727989 (0.000000 0.000000 1.000000)
   LINE: 119.519989 82.727989 (0.000000 0.000000 1.000000)
   LINE: 208.800003 153.143997 (0.000000 0.000000 1.000000)
   LINE: 208.800003 153.143997 (0.000000 0.000000 1.000000)
   LINE: 208.800003 153.143997 (0.000000 0.000000 1.000000)
   LINE: 253.440002 188.351990 (0.000000 0.000000 1.000000)
   LINE: 253.440002 188.351990 (0.000000 0.000000 1.000000)
   LINE: 298.079987 223.559998 (0.000000 0.000000 1.000000)
   LINE: 298.079987 223.559998 (0.000000 0.000000 1.000000)
   LINE: 342.720001 258.768005 (0.000000 0.000000 1.000000)
   LINE: 342.720001 258.768005 (0.000000 0.000000 1.000000)
   LINE: 387.359985 293.976013 (0.000000 0.000000 1.000000)
   LINE: 387.359985 293.976013 (0.000000 0.000000 1.000000)
   LINE: 432.000000 329.183990 (0.000000 0.000000 1.000000)
   LINE: 432.000000 329.183990 (0.000000 0.000000 1.000000)
   LINE: 476.639984 364.391998 (0.000000 0.000000 1.000000)
   LINE: 476.639984 364.391998 (0.000000 0.000000 1.000000)
   LINE: 521.280029 399.600006 (0.000000 0.000000 1.000000)

On my system, I see the following:

   LINE: 116.203125 92.433594 (0.000000 0.000000 1.000000)
   LINE: 159.601563 126.660156 (0.000000 0.000000 1.000000)
   LINE: 159.601563 126.660156 (0.000000 0.000000 1.000000)
   LINE: 203.000000 160.890625 (0.000000 0.000000 1.000000)
   LINE: 203.000000 160.890625 (0.000000 0.000000 1.000000)
   LINE: 246.402344 195.121094 (0.000000 0.000000 1.000000)
   LINE: 246.402344 195.121094 (0.000000 0.000000 1.000000)
   LINE: 289.800781 229.351563 (0.000000 0.000000 1.000000)
   LINE: 289.800781 229.351563 (0.000000 0.000000 1.000000)
   LINE: 333.199219 263.578125 (0.000000 0.000000 1.000000)
   LINE: 333.199219 263.578125 (0.000000 0.000000 1.000000)
   LINE: 376.597656 297.808594 (0.000000 0.000000 1.000000)
   LINE: 376.597656 297.808594 (0.000000 0.000000 1.000000)
   LINE: 420.000000 332.039063 (0.000000 0.000000 1.000000)
   LINE: 420.000000 332.039063 (0.000000 0.000000 1.000000)
   LINE: 463.398438 366.265625 (0.000000 0.000000 1.000000)
   LINE: 463.398438 366.265625 (0.000000 0.000000 1.000000)
   LINE: 506.796875 400.496094 (0.000000 0.000000 1.000000)

OK.  Can't rule out multiple issues happening that might be confusing matters.

To get some insight, it might be useful to compare the contents of the feedback buffer between a properly working system (wouldn't have to be any particular kind, I think).  That is, after calling

         opengl_renderer::draw (go);

place a short hunk of code that sends the contents of

gl2ps->feedback

to a binary file.  One can then do a binary comparison between feedback data for a working system and non-working system--sort of pick apart what may be happening.  If the binary data compares exactly, then it could be that gl2ps has a bug or is using an incompatible header definition for the API.  If the binary data doesn't compare exactly, then one could open the files in a binary editor and search for the hex equivalents to the tokens that OpenGL is using.  Does that sound like more work than the help it would yield?

[
This is an aside, but I think that this feedback mode really could be the source of the temporary flash of colors I see.  In the gl2ps code I only see the one instance where the render mode is changed back to GL_RENDER.  I.e.,

static GLint gl2psPrintPrimitives(void)
{
  GL2PSbsptree *root;
  GL2PSxyz eye = {0.0F, 0.0F, 100.0F * GL2PS_ZSCALE};
  GLint used;

  used = glRenderMode(GL_RENDER);

  if(used < 0){
    gl2psMsg(GL2PS_INFO, "OpenGL feedback buffer overflow");
    return GL2PS_OVERFLOW;
  }

  if(used > 0)
    gl2psParseFeedbackBuffer(used);

What happens if during the time that the Qt figure window attempts to redraw the figure?  At least the feedback buffer is cleared from memory after the render mode is turned back to GL_RENDER.  Otherwise doing an asynchronous replot in a different thread would be a problem...  BTW, it might be useful to print out the value of "used" in the above gl2ps code.
]

The gl2ps documentation could be a tad clearer on what it is doing.  I mean, now I understand more having seen the innards.  However, the statement about gl2ps culling primitives is not an accurate one.  The culling actually happens prior to gl2ps and gl2ps has culling simply as a matter of consequence.  Here's documentation on the glFeedbackBuffer routine:

https://msdn.microsoft.com/en-us/library/windows/desktop/dd373532(v=vs.85).aspx

http://www.glprogramming.com/red/chapter13.html

Note that

"
Each block begins with a code indicating the primitive type, followed by values that describe the primitive's vertices and associated data. The glFeedbackBuffer function also writes entries for bitmaps and pixel rectangles. Feedback occurs after polygon culling and glPolygonMode interpretation of polygons has taken place, so polygons that are culled are not returned in the feedback buffer. It can also occur after polygons with more than three edges are broken up into triangles, if the OpenGL implementation renders polygons by performing this decomposition.
"

All right that pretty much confirms that the primitives are culled before reaching gl2ps.

FWIW, if intricate debugging is required, it's possible to put some marker tokens in the feedback buffer data using glPassThrough:

"
You can insert a marker into the feedback buffer with glPassThrough.
"

OK, so why is OpenGL culling lines when sent to the feedback buffer as opposed to one of the video drivers?  Is there something configuring the image size that is supposed to be used by OpenGL for the feedback buffer?  Some other obscure setting?

OK, one question is whether this is a strictly Qt issue.  I was under that impression, but I'm not certain if there's even a distinction.  Both Qt and fltk use the _opengl_print_.m command.  So, even though Qt and fltk are different frameworks, it may be the environment of the executing program that influences the behavior.  And that environment may be attributed to Qt in the case of GUI operation and --no-gui operation.  In terms of environment, --no-gui and normal operation are the same.  It's the --no-gui-libs option which results in a different underlying environment.

Question:  When you say you are seeing the same behavior in FLTK as in Qt, is that using the --no-gui-libs option?

Oh, I see.  Looking at the patch https://savannah.gnu.org/support/download.php?file_id=33932 I now have a little better understanding of the way gl2ps works.  There is a possibility this is a thread timing issue.  Not 100% sure, but I'll explain.

Contrary to what I was thinking, the gl2ps code is not operating directly on shared memory in threads.  There is some kind of feedback feature in OpenGL that gl2ps is using to get a copy of the plot contents in a memory buffer.  gl2ps then operates on that feedback buffer.

In gl2ps-renderer.cc, the general sequence of events is

  gl2psBeginPage();
  old_print_cmd = print_cmd;
  opengl_renderer::draw(go);
  glFinish();

It's inside gl2psBeginPage where the acquisition of the data occurs:

  gl2ps->feedback = (GLfloat*)gl2psMalloc(gl2ps->buffersize * sizeof(GLfloat));
  glFeedbackBuffer(gl2ps->buffersize, GL_3D_COLOR, gl2ps->feedback);
  glRenderMode(GL_FEEDBACK);

There is a buffer created, that buffer is set up as the feedback buffer OpenGL will use, then opengl_renderer::draw(go) fills in that memory--at least that is how I understand it.  However, isn't it the case that opengl_renderer could have some element of it that has main thread affinity, not the interpreter thread?  If so, something in the opengl_renderer::draw chain of events could end up queued across threads in Qt.  Then there will be a race condition.  The ::draw will be filling in the contents of gl2ps->feedback while the code in the interpreter thread continues onward.  My guess is that most of the time Martin sees random graphics because that feedback buffer is yet to be filled when gl2ps operates on it.  However, it may be the case that once in a while ::draw finishes some of the plot before gl2ps operates on it, but it is never the complete plot, i.e., the elements we've discussed as being dropped aren't in the feedback buffer yet.

It seems to me that in the following code there might need to be a semaphore wait as noted by []:

          if (ret == GL2PS_ERROR)
            {
              old_print_cmd.clear ();
              error ("gl2ps-renderer::draw: gl2psBeginPage returned GL2PS_ERROR");
              return;
            }

          old_print_cmd = print_cmd;

          opengl_renderer::draw (go);

 [Need some kind of Mutex handshake right here to make ]
 [sure the above operation has completed if the draw is]
 [being done in the main thread.                       ]

          // Without glFinish () there may primitives be missing in the
          // gl2ps output.
          glFinish ();

Just my thoughts.  There is a possibility this could be the source of the strange graphics I see when printing in Qt.  That is, Qt redraw/rendering while in GL_FEEDBACK mode maybe, perhaps?  Maybe that has a strange effect.  Don't know.

Dan, I modified gl2ps so that it prints the list of verices as it gathers them from the OpenGL buffer.  The vertices are already screwed up at that point.  So it seems unlikely that gl2ps is to blame, though I suppose it is still possible somehow.  I'm attaching my gl2ps changes in case anyone else would like to experiment with them and maybe get some clue about what could be happening.

(file #33932)

Hmm, well, now I have a report that my current build of 3.8.2 fails but an older version that I built around the time of the 3.8.2 release works properly.

I have no idea what dependency or build tool has changed that could cause that.

Response to Dan (comment #24)

I did not change settings after installation, so both machines produce plots with default settings. The axes equivalent to figure position is axis position, right?

I ran the test script again on both machines and checked the properties of figure 2:

>> get (2,"position")
ans =
   300   200   560   420
>> get (0,"defaultfigureposition")
ans =
   300   200   560   420
>> get (get (2,"children") , "position")
ans =
   0.13000   0.11000   0.77500   0.81500
>> get (0,"defaultaxesposition")
ans =
   0.13000   0.11000   0.77500   0.81500

The results are exactly the same on both systems.

The second test you proposed was not so easy to perform because, as I wrote before, the result is not deterministic: Sometimes the curve is fine, sometimes broken, sometimes it has wild lines. Same for the axes, it needed several runs until I got an EPS with green background and a missing axis. The file f2greenBG.eps was created on the "problematic" machine 1 with the following commands:

figure();
fflush(stdout);
x = 1:1000;
y = sin (x/300);
plot (x,y);
set(gca, 'color', [0 1 0])
xlabel ("Time in s")
ylabel ("\\Omega")
fprintf ("\nSaving figure 2\n");
print -dpng -r0 f2.png
print -dpdf -r0 f2.pdf
print -dsvg -r0 f2.svg
print -depsc -r0 f2.eps

After creation, I renamed the file from f2.eps to f2greenBG.eps in order to prevent it from being overwritten.

To me it seems pretty clear that the x-axis is really missing, not covered - the lower background triangle is missing and opening the EPS with Inkscape I cannot find a line for the axis.

Doesn't the randomness of the error indicate that Rik is probably right and we are facing something thread-related here, a race condition maybe? One big difference between my two systems is that the machine that produces faulty files is much faster than the other (3.3GHz with graphics card vs. 2.4GHz with onboard graphics).

(file #33925)

As far as I can tell, this is not a problem with gl2ps.  When gl2ps gets the vertex data from the OpenGL buffer it is already screwed up.

@Rik (comment #18) You mean using a build that does not include Qt, right? In case you don't, I started "standard" Octave 4.0.0-rc4 with the option you proposed...

C:\Octave\Octave-4.0.0-rc4\bin>octave.exe --no-gui-libs

... and ran the test script again. The results look like before, missing curve segments and missing axes.

Hi and sorry for the delay, I can only test this at work because on my PC at home this problem does not show up.

First I deinstalled rc3 and installed rc4 from alpha.gnu.org on both machines. Like before, machine 1 produces faulty files from fltk figures, machine 2 produces correct files.

Some graphics-related info on the two systems retrieved with GLview:
Machine 1
=========
Renderer: ATI Radeon HD 5450
Operating System: Microsoft Windows 7 Enterprise
Processor: Intel Core i3-2120 CPU @ 3.30GHz, Sandy Bridge, Family 6h, Model: 2ah, Stepping: 7h
OpenGL version: 4.2
Driver version: 9.12.0.0 Catalyst 9.012 19-Dez-12

Machine 2
=========
Renderer: Mobile Intel 4 Series Express Chipset Family
Operating System: Microsoft Windows 7 Enterprise
Processor: Intel Core 2 Duo CPU P8600 @ 2.40GHz, Penryn, Family 6h, Model: 17h, Stepping: ah
OpenGL version: 2.1
Driver version: 8.15.10.2302 11-Feb-11

(Typos possible, but I double-checked the version numbers)


I don't have Octave 3.8.2 at hand, but 3.8.0 is still installed so I ran the test script there. Guess what: I get basically the same faults in the saved files, see the attached f3_octave3.8.0.eps as an example.

After this test I switched back to 4.0.0-rc4

In the next step I replaced print.m and restarted Octave 4.0.0-rc4 as you suggested in comment #13. I do get the expected output:

+verbose+
epstool command: ' cat > "foo.eps" '
opengl-pipeline: ' cat > "foo.eps" '
-verbose-

foo.eps is attached. The axes look fine, but the line starts at (2,2), not (1,1) as one would expect!

I switched back to the original print.m and replaced liboctinterp-3.dll as suggested in comment #14. Octave 4.0.0-rc4 was started after replacing the file. The line in the printed figure still starts at (2,2), not (1,1) (see the attached fooDifferentLiboctinterp.eps).

You can count on me continuing to run tests on this issue in the future because it is really troublesome for my daily work.

(file #33897, file #33898)

I'm tagging this as a blocker and a regression as I'm told that even on systems where printing is failing now it used to work with 3.8.2.  It seems important to me that we have printing working correctly with the new release.

When I say it worked previously with 3.8.2, I mean that it worked on the same hardware and system with 3.8.2 where we see the failure with the current release candidate.  I'm attaching the changes I made to generate the modified liboctinterp-3.dll file that I posted.  These changes reverse nearly all of the changes to gl2ps-renderer.{h,cc} that have been made since 3.8.2.

(file #33867)

Could you try replacing the file share\octave\4.0.0-rc4\m\plot\util\print.m with the attached version and then try

  plot (1:10)
  print ("foo.eps", "-depsc", "-debug")

and then attach the resulting foo.eps file here?

Be sure to restart Octave after replacing the print.m file so that the new version is used instead of any previous version that Octave has already parsed.

This time, you should see

  epstool command: ' cat > 'foo.eps' '
  opengl-pipeline: ' cat > foo.eps '

My goal here is to capture the output directly from gl2ps to see whether it is corrupted.  I think that should narrow the problem down to either gl2ps or ghostscript.

(file #33843)

I executed the commands you proposed in your last comment on the second machine (the one that produces good files) and got exactly the same results as on the problematic machine (checked with diff).

What does the following show for you in the command window?

+verbatin+
  plot (1:10)
  print ('foo.eps', '-depsc', '-debug')
-verbatim-

I think it should print something like

  epstool command: 'C:\Users\jwe\Desktop\octave-2015-04-29-15-58\bin\gs.exe -dQUIET -dNOPAUSE -dBATCH -dSAFER -sDEVICE=eps2write -sOutputFile=""foo.eps"" -'
  opengl-pipeline: 'C:\Users\jwe\Desktop\octave-2015-04-29-15-58\bin\gs.exe -dQUIET -dNOPAUSE -dBATCH -dSAFER -sDEVICE=eps2write -sOutputFile=""foo.eps"" -'

in the Octave command window.  Also, what does

  system ("gs -v")

return for you?

I still haven't been able to duplicate the problem after multiple runs of the plotTest script.  Hmm..

Of course! I added eps output to my script with:

print -depsc -r0 f1.eps

You find f(1|2|3).eps attached. Note that the behaviour of print() is not deterministic, first because of the irregular occuring error described in bug #44915 and second because the appearance of the figures changes when I run the script several times in a row. Figure 3 had the strange extra lines in the PDF uploaded earlier, now I saw the curve with a broken line (but no extra lines) or even a solid line (the bottom axis, however, is still missing). PDF, PNG and EPS look the same.

Could you please generate EPS equivalents of the figures and attach?  I.e., print -depsc.

One of the concerns I've had about the approach of creating all output formats as derivative of the EPS file is aliasing effects and other unexpected behavior with the ps2xyz translation.

Hi,

Thanks for your bug report.
The Greek letters not being printed correctly is a known issue (see bug #42320). The fact that it works in svg format when using utf8 characters is because svg unlike eps (from which pdf and png are converted) does handle utf8 natively if the viewer does.

Does FLTK also produce missing axes and corrupted lines?