bugGNU Octave - Bugs: bug #42534, No lines when printing fltk plot...

 
 

bug #42534: No lines when printing fltk plot with Intel graphics on Windows

Submitted by:  Helios De Rosario <heliosdr>
Submitted on:  Tue 10 Jun 2014 02:58:35 PM UTC  
 
Category:  Plotting with OpenGL Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Invalid Assigned to:  None
Originator Name:  Helios De Rosario Open/Closed:  Closed
Release:  3.8.1 Operating System:  Microsoft Windows

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)

Fri 03 Mar 2017 04:23:09 AM UTC, comment #54:

Just to answer a question that seems to remain unanswered.
The same bug affects Linux with Nvidia drivers and Intel chipsets.
The issue is still in 4.3.0+

Juan Pablo Carbajal <juanpi>
Project Member
Mon 29 Aug 2016 10:19:16 PM UTC, comment #53:

Apologies, wrong tab, this was meant for #47914

Person <mycae>
Mon 29 Aug 2016 10:17:09 PM UTC, comment #52:

Hi,

I'm a random octave user, and I am finding this in my own C++ applications when compiled with ubsan. I have the same backtrace (different symbol position, but same ubsan error and stack depth).

I found this bug when searching for the crash message - perhaps this is indeed a problem with the video driver...

I'm using debian testing (x86_64), octave 4.0.3-1, as a virtualbox guest (4.3.30 r101610).

I've fired off a rebuild of the octave package with ubsan enabled, but it looks like it might take a while - I'll get back when I have an ubsan-enabled octave to test.

$ glxinfo |head -n 60
libGL error: pci id for fd 4: 80ee:beef, driver (null)
OpenGL Warning: Failed to connect to host. Make sure 3D acceleration is enabled for this VM.
libGL error: core dri or dri2 extension not found
libGL error: failed to load driver: vboxvideo
name of display: :0.0
display: :0  screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.4
server glx extensions:
    GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap,
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer,
    GLX_OML_swap_method, GLX_SGIS_multisample, GLX_SGIX_fbconfig,
    GLX_SGIX_pbuffer, GLX_SGI_make_current_read
client glx vendor string: Mesa Project and SGI
client glx version string: 1.4
client glx extensions:
    GLX_ARB_create_context, GLX_ARB_create_context_profile,
    GLX_ARB_create_context_robustness, GLX_ARB_fbconfig_float,
    GLX_ARB_framebuffer_sRGB, GLX_ARB_get_proc_address, GLX_ARB_multisample,
    GLX_EXT_buffer_age, GLX_EXT_create_context_es2_profile,
    GLX_EXT_create_context_es_profile, GLX_EXT_fbconfig_packed_float,
    GLX_EXT_framebuffer_sRGB, GLX_EXT_import_context,
    GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating,
    GLX_INTEL_swap_event, GLX_MESA_copy_sub_buffer,
    GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer,
    GLX_MESA_swap_control, GLX_OML_swap_method, GLX_OML_sync_control,
    GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer,
    GLX_SGIX_visual_select_group, GLX_SGI_make_current_read,
    GLX_SGI_swap_control, GLX_SGI_video_sync
GLX version: 1.4
GLX extensions:
    GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context,
    GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating,
    GLX_MESA_copy_sub_buffer, GLX_MESA_multithread_makecurrent,
    GLX_MESA_query_renderer, GLX_OML_swap_method, GLX_SGIS_multisample,
    GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGI_make_current_read
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: VMware, Inc. (0xffffffff)
    Device: llvmpipe (LLVM 3.8, 128 bits) (0xffffffff)
    Version: 11.2.2
    Accelerated: no
    Video memory: 2971MB
    Unified memory: no
    Preferred profile: core (0x1)
    Max core profile version: 3.3
    Max compat profile version: 3.0
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.0
OpenGL vendor string: VMware, Inc.
OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.8, 128 bits)
OpenGL version string: 3.0 Mesa 11.2.2
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:
    GL_AMD_conservative_depth, GL_AMD_draw_buffers_blend,
    GL_AMD_seamless_cubemap_per_texture, GL_AMD_shader_stencil_export,
    GL_AMD_shader_trinary_minmax, GL_ANGLE_texture_compression_dxt3,
    GL_ANGLE_texture_compression_dxt5, GL_APPLE_packed_pixels,
    GL_APPLE_vertex_array_object, GL_ARB_ES2_compatibility,
    GL_ARB_ES3_compatibility, GL_ARB_arrays_of_arrays, GL_ARB_base_instance,
    GL_ARB_blend_func_extended, GL_ARB_buffer_storage,
    GL_ARB_clear_buffer_object, GL_ARB_clip_control,
    GL_ARB_color_buffer_float, GL_ARB_compressed_texture_pixel_storage,

Person <mycae>
Tue 10 Mar 2015 01:46:52 PM UTC, comment #51:

The problem with the ATI Radeon is probably the same as that with Intel.  The manufacturer has a hardware implementation of the OpenGL API which is not fully compliant to the specification.

Rik <rik5>
Project Administrator
Tue 10 Mar 2015 12:49:50 PM UTC, comment #50:

@ comment #49 : on my computer, the bug doesn't happen with the Intel graphic card but on the AMD/ATI Mobility Radeon HD 5650 card. The Intel graphic card produces awful looking plots but they aren't truncated.

Stephen L. <lrq3000>
Mon 09 Mar 2015 08:46:46 PM UTC, comment #49:

I guess comment #39 quoting from the OpenGL FAQ is accurate, Intel just doesn't have a correct implementation of the OpenGL specification and the only way around it is to avoid Intel HW.  This can be accomplished either by switching to another video card (like Nvidia), or switching to software rendering (Mesa), or avoidng OpenGL entirely by using the gnuplot toolkit.

Rik <rik5>
Project Administrator
Mon 09 Mar 2015 07:29:07 PM UTC, comment #48:

I have just tested 4.0-RC1, and it doesn't fix the problem. Note that the code by Helios does not always produce the bug (although it often does).

Here is a specific instance that always produces the bug (attached is the resulting image):

graphics_toolkit fltk
A= [-1.866809
  -1.005976
  -0.204308
  -0.632928
  -0.075195
   0.016177
  -0.561073
   1.045011
   0.994689
  -0.853104]
plot(A, "o-")
grid on
print testplot.png


Stephen L. <lrq3000>
Sun 08 Mar 2015 02:02:50 AM UTC, comment #47:

There is now a 4.0 release candidate available at ftp://alpha.gnu.org/gnu/octave/.  Can someone with the appropriate Intel hardware download and see if the issue still exists?

Rik <rik5>
Project Administrator
Sat 14 Feb 2015 05:46:04 PM UTC, comment #46:

This bug seems very similar to bug #44125 which was just fixed.  Can someone try to build an MXE Octave version with Octave development sources with changeset 1a6fa5a523e4 or newer?

Rik <rik5>
Project Administrator
Thu 06 Nov 2014 04:03:56 PM UTC, comment #45:

Sorry in my previous comment I have meant to say to use this command to switch to gnuplot:

graphics_toolkit('gnuplot');

And about my Intel HD Graphics processor, the model is Intel64 Family 6 Model 37 Stepping 5 at 2793 MHz with driver version 8.15.10.2202.

Stephen L. <lrq3000>
Thu 06 Nov 2014 03:56:28 PM UTC, comment #44:

I have the exact same problem popping up randomly from time to time since quite a lot of time (if I have to guess I'd say since I use Octave, I started with version 3.2).

I am quite glad this issue as at last being investigated seriously, this has been a huge hindrance for me and other users facing the same issue.

I have just tested on my laptop running Windows 7 64-bit. It has two graphical cards: Intel Integrated GPU, and a higher performance AMD/ATI Mobility Radeon HD 5650. After reading your discussion, I tried to switch between the two: the AMD produces truncated curves, while the Intel Integrated GPU produces the correct plots (although awfully looking, the text fonts aren't even the same as on-screen).

Another solution I have come up with is to use gnuplot instead of fltk with:

graphics_toolkit('fltk');

In this case, I have no problem anymore when printing into a file, whatever the graphic card.

Stephen L. <lrq3000>
Thu 09 Oct 2014 07:04:43 AM UTC, comment #43:

Sergey:  IIRC I had the same problem on my AMD Radeon machine (with APU).  Some of the lines had holes in them, or were simply missing points (only in the printed result).  I will do some extended testing on my AMD laptop and report back.

Regarding Mesa drivers, these technically should always provide a complete, albeit much slower result, since it is software rendering and no transient, buggy hardware drivers are in the mix. From the FAQ on the Mesa project's website:

Software rendering with Mesa serves as a reference for validating the hardware drivers.

So if the printing is not working with Mesa OpenGL on a certain setup, then I would tend to say that it isn't the OpenGL backend that would be causing the problem in such a particular case, unless some new, fancy OpenGL extensions are involved :)

Andreas:
The Mesa drivers did solve the problem for me on Windows 7 x64 :)
On my "Intel HD Graphics" machine, I cannot obtain administrator rights.  I can say though, that some manner of Intel GPU drivers appear to be installed (as evidenced by the system tray icon and device manager), and that 3d rendering does seem to work.

Bradley Manning <mmx1337>
Tue 07 Oct 2014 04:04:21 PM UTC, comment #42:

I've had a short opportunity to test my Octave build on laptops with different integrated graphics adapters, and here are some results:

1. Update of Intel GPU drivers does imrove things but does not solve the issue completely, on some more sophisticated charts primitives may still be missing -- in my case a couple of bars on a bar chart being plotted in subplot(2,1,1).
1. When tested on some older (>3 yrs old) laptops with ATI Radeon integrated graphics, the problem shows up in an even worse light -- apart from missing primitives, some lines' points are being connected in a wrong order, even though they looked fine on a screen. Unfortunately there were no available driver updates on a laptop manufacturer's web site, but when I used the same Octave build on a fresh Ubuntu 14.04, being installed on those machines, I had no issues with the same charts. So this is most likely the issue of win drivers. But with ATI in this case.
1. Putting Mesa opengl32.dll from the qt-project site to the Octave's bin folder didn't help in eiher cases

In all cases I used exatly the same Octave build on a freshly installed Windows 7.

sergey plotnikov <nul0m>
Tue 07 Oct 2014 08:23:00 AM UTC, comment #41:

I've added a FAQ entry here: http://wiki.octave.org/FAQ#Missing_lines_when_printing_under_Windows_with_OpenGL_toolkit_and_Intel_integrated_GPU

@Bradley, Helios, Sergey, Paolo: Could you help extend that FAQ stub? Have you had success with the Mesa drivers for Windows and have you tried to install the Intel OpenGL driver for your hardware?

If there is nothing we can do further I would like to close this bug report as invalid.

Andreas Weber <andy1978>
Project Member
Mon 06 Oct 2014 06:44:36 AM UTC, comment #40:

I second Andreas.  An entry in the FAQ is absolutely necessary, as it seems to be definitely a problem of Intel GPUs, and not a problem of Octave per se.

Bradley Manning <mmx1337>
Sun 28 Sep 2014 06:02:28 PM UTC, comment #39:

I want to cite https://www.opengl.org/wiki/FAQ : "However, of the non-defunct ones, this is most likely to happen with Intel's integrated GPUs. Intel does not provide a proper, up-to-date OpenGL implementation for their integrated GPUs. There is nothing that can be done about this... Another reason is that you haven't installed your video card drivers after installing your OS."

So my question is: have you all installed up to date intel drivers for your GPU? Without these your OS might fall back to a default OpenGL 1.1 implementation (opengl32.dll).

Another workaround might be to install Mesa drivers from http://qt-project.org/wiki/Cross-compiling-Mesa-for-Windows

But after all I don't think this is a bug in octave (not even in FLTK) and I suggest we create a wiki page for this problem and link it from Octaves FAQ.

Andreas Weber <andy1978>
Project Member
Fri 26 Sep 2014 12:58:49 PM UTC, comment #38:

Sorry for the confusion, my graphic card is Intel HD Graphics 2500, so I also confirm.

Thanks Andreas for the advice.

Helios De Rosario <heliosdr>
Fri 26 Sep 2014 09:08:38 AM UTC, comment #37:

Yes, Bradley, my laptop has Intel HD Graphics 3000 adapter, so it may only confirm your hypothesis.

Although quick try of mesa3d driver on a Win7 VM helped just partially -- less lines are missing now when I print a simple chart. And what is strange the printing result also depends on whether I use print('-depsc','test.eps') or drawnow('eps','cat>test.eps') command. In the latter case I see no missing lines.

@andreas: it was me who you have discussion on IRC with (we were trying that GL2PS_OCCLUSION_CULL disabling)

sergey plotnikov <nul0m>
Fri 26 Sep 2014 08:00:11 AM UTC, comment #36:

Yes: Intel Core i3-3240 CPU in my machine.

Helios De Rosario <heliosdr>
Fri 26 Sep 2014 06:19:17 AM UTC, comment #35:

Sergey, Helios, do your systems that exhibit this bug also have Intel GPUs, or is your hardware setup different?

Bradley Manning <mmx1337>
Thu 25 Sep 2014 11:22:34 AM UTC, comment #34:

Yes, Mike, this seems to be the issue.

I am not sure about hardware-accelerated rendering on Linux with an Intel GPUs, because I can only try plot printing on Linux in a VM with the Intel card.  If you can verify this, then we will have definitely narrowed down this bug!

Bradley Manning <mmx1337>
Thu 25 Sep 2014 10:49:30 AM UTC, comment #33:

So to summarize, the bug is that printing plots to a file, using the fltk toolkit, on a Windows OS, with an Intel video card, produces a figure with no line drawn. Is that accurate?

FWIW, this works fine using direct rendering on an Intel video card on a Linux distribution (just so it's clear that this is Windows-specific).

Mike Miller <mtmiller>
Project Administrator
Thu 25 Sep 2014 10:35:16 AM UTC, comment #32:

Success!

I downloaded the Mesa drivers binary (from http://qt-project.org/wiki/Cross-compiling-Mesa-for-Windows) and placed it into the bin directory alongside the Octave executables.  Now Octave prints as it should!

You might have to set LIBGL_ALWAYS_SOFTWARE in your MSYS/Windows environment variables (see http://www.mesa3d.org/envvars.html).

Bradley Manning <mmx1337>
Thu 25 Sep 2014 08:54:42 AM UTC, comment #31:

After multiple tests, I figured that this could likely the issue.  I tried stock mxe-octave on a machine with an AMD APU (Radeon) on Windows x64, and printing worked fine.  The machine that is having problems is of course running Windows x64, but has an Intel GPU.  On the Intel GPU machine, printing with Octave 3.8.2 functions perfectly in an OpenSUSE VM, albeit with software rendering. 

The changes to gl2ps-renderer.cc that Andreas suggested did not work, as far as I can tell.  My cross-compiled version (x86) generates some errors upon printing, but on the AMD GPU machine the plot lines show up, and on the Intel GPU machine they do not.

Example output:

>> sombrero(10)
>> drawnow('eps','cat>testOut.eps')
error: get: unknown axes property fontsize_points
error: octave_base_value::double_value (): wrong type argument '<unknown type>'
error: octave_base_value::convert_to_str_internal (): wrong type argument '<unknown type>'
error: octave_base_value::convert_to_str_internal (): wrong type argument '<unknown type>'
error: octave_base_value::convert_to_str_internal (): wrong type argument '<unknown type>'
error: octave_base_value::convert_to_str_internal (): wrong type argument '<unknown type>'
error: octave_base_value::convert_to_str_internal (): wrong type argument '<unknown type>'
error: octave_base_value::matrix_value(): wrong type argument '<unknown type>'
error: octave_base_value::matrix_value(): wrong type argument '<unknown type>'
error: octave_base_value::matrix_value(): wrong type argument '<unknown type>'
error: drawnow: A(I,J): row index out of bounds; value 1 out of bound 0
>> print -dsvg testOut.svg
error: get: unknown axes property fontsize_points
error: octave_base_value::double_value (): wrong type argument '<unknown type>'
error: octave_base_value::convert_to_str_internal (): wrong type argument '<unknown type>'
error: octave_base_value::convert_to_str_internal (): wrong type argument '<unknown type>'
error: octave_base_value::convert_to_str_internal (): wrong type argument '<unknown type>'
error: octave_base_value::convert_to_str_internal (): wrong type argument '<unknown type>'
error: octave_base_value::convert_to_str_internal (): wrong type argument '<unknown type>'
error: octave_base_value::matrix_value(): wrong type argument '<unknown type>'
error: octave_base_value::matrix_value(): wrong type argument '<unknown type>'
error: octave_base_value::matrix_value(): wrong type argument '<unknown type>'
error: drawnow: A(I,J): row index out of bounds; value 1 out of bound 0
error: called from:
error:   C:\Users\bradley.manning\Desktop\octave-3.8.2_glfix\share\octave\3.8.2\m\plot\util\private\__fltk_print__.m at line 166, column 5
error:   C:\Users\bradley.manning\Desktop\octave-3.8.2_glfix\share\octave\3.8.2\m\plot\util\print.m at line 422, column 14
>>

In the example, the files are generated, just without plot lines (despite the errors).

I am trying to cross-compile a version on a Linux 64-bit distro with the changes to gl2ps-renderer.cc for due diligence .. (configure options:  --enable-lib64-directory, --enable-windows-64, --disable-java)

My question is, is there a way to force Octave to use software rendering?  Unfortunately, on the problem machine I do not have administrator rights, so using the option in the Windows Control Panel isn't an option (see http://www.wikihow.com/Turn-off-Hardware-Acceleration).  It would be great if I could disable hardware acceleration inside of Octave to test if this solves the issue.  I read that one can put the Mesa3d OpenGL drivers in the same folder as an application, and it will resort to using those instead of the default drivers on the system.  I will try this.

Bradley Manning <mmx1337>
Thu 25 Sep 2014 12:09:48 AM UTC, comment #30:

I had the exact same problem in a laptop with dual gpu (Nvdia optimus + intel hd), forcing Octave to use the nvidia gpu fixed the issue.

So something with fltk and intel gpu's isn't working.

Anonymous
Thu 18 Sep 2014 10:18:39 AM UTC, comment #29:

Thanks for the tips, Andreas.  After looking at the sources, it seems that truly all of the dirty work is done in italic void
glps_renderer::draw( ... ) italic.  My initial guess was that, for some reason, the graphics primitives were just not being drawn by the call italic opengl_renderer::draw (go) italic in the italic gl2psBeginPage / gl2psEndPage italic block.

I saw the issue with OCCLUSION_CULL in this discussion; though, I didn't think to try it myself because the plot lines do not show up even with italic axis off italic.  I will try your suggestions and post back here! :)

Bradley Manning <mmx1337>
Thu 18 Sep 2014 10:04:02 AM UTC, comment #28:

Hi Bradley, the "drawnow..." hack directly saves the output of gl2ps to test.eps (EPS is the default output of gl2ps in octave) without using the fltk-pipeline. So no ghostscript or epstool is used. Only if you use other formats like SVG, PS, PNG, JPEG... ghostscript is used to convert the .eps (This is only true when using graphics_toolkit fltk)

If you want to help debug this just 2 ideas I have what could be the problem:

1.) The white axes background and the lines in the foreground are drawn so tight in z-direction that the algorithm for OCCLUSION_CULL in gl2ps thinks the lines are behind the white background and removes them. You could remove GL2PS_OCCLUSION_CULL in gl2ps-renderer.cc (http://hg.octave.org/octave/file/14bb81940528/libinterp/corefcn/gl2ps-renderer.cc#l98), and see if the generated eps contains the lines in the file and if they are hidden behind white triangles. Another entry would be to see how the z-position is calculated in gl-renderer.cc::draw_line.

2.) Another idea is that there are timing problems where gl2ps finishes before your graphic driver painted all OpenGL content. I've fixed this on the default branch in cset http://hg.octave.org/octave/rev/c9f960441513 using glFlush() to force the execution of GL commands. You can try this by replacing gl2ps-renderer.cc in your MXE build with the one on the default branch.

Andreas Weber <andy1978>
Project Member
Thu 18 Sep 2014 09:32:24 AM UTC, comment #27:

Hello Andreas,
With your commands, I still see no plot lines in the EPS file :( 
I will try to build a debug version of MXE Octave tonight and see how far I come.  I just seems as if graphics primitives like line, patch, etc. are not making it through the pipeline.

(file #32131)

Bradley Manning <mmx1337>
Thu 18 Sep 2014 09:17:48 AM UTC, comment #26:

Hi Bradley, can you try

graphics_toolkit fltk
plot(rand(3))
drawnow("eps","cat>test.eps")

This should create test.eps with 3 lines.

Andreas Weber <andy1978>
Project Member
Thu 18 Sep 2014 08:48:36 AM UTC, comment #25:

Yes, I have viewed the printed files in GSview.  The plot lines are not visible.  The plot line (sine curve) is also not in the SVG file.  This can be verified also by opening the SVG in a text editor and by deleting elements (it is relatively human-readable), thereafter checking the rendered SVG output.  The only entries in the SVG are the plot window, ticks, and tick values.

Here is the code I used...

>> plot(0:pi/64:2*pi,sin(0:pi/64:2*pi))
>> print -dsvg test123.svg -debug
fltk-pipeline: 'cat > test123.svg'
>> print -color -deps test123.eps -debug
epstool command: 'C:\Users\bradley.manning\Documents\Software\octave-3.8.2-1-portable\octave-3.8.2\bin\gs.exe -dQUIET -dNOPAUSE -dBATCH -dSAFER -sDEVICE
=epswrite -sOutputFile=""test123.eps"" -'
fltk-pipeline: 'C:\Users\bradley.manning\Documents\Software\octave-3.8.2-1-portable\octave-3.8.2\bin\gs.exe -dQUIET -dNOPAUSE -dBATCH -dSAFER -sDEVICE=e
pswrite -sOutputFile=""test123.eps"" -'

Please see the files test123.eps and test123.svg :)

(file #32128, file #32129)

Bradley Manning <mmx1337>
Tue 16 Sep 2014 11:02:04 AM UTC, comment #24:

How have you viewed and inspected the generated EPS files? With GSview http://pages.cs.wisc.edu/~ghost/gsview/index.htm ?

Andreas Weber <andy1978>
Project Member
Tue 16 Sep 2014 08:21:03 AM UTC, comment #23:

I can also confirm this bug on Windows 7 (x64), using MXE 3.8.2-1 Portable, with epstool 3.08.  Additionally I have tried hiding the axes with "axis off" and saving as PNG with "print ("-dpngalpha", "figure.png")".  Plot lines are just not saved, but certain plot symbols are ("O" and "+"). 

With the gnuplot backend, saving as an EMF file does work for simple plots; however, my plots are quite complicated.  As such, gnuplot doesn't plot anything, and crashes during EMF export.

Bradley Manning <mmx1337>
Mon 08 Sep 2014 12:32:53 PM UTC, comment #22:

I can confirm same bug on Win 7 x64 with MXE 3.8.2-2 from http://mxeoctave.osuv.de/ and gs9.14

Paolo

Paolo Manganelli <pmanganelli>
Mon 01 Sep 2014 08:06:30 AM UTC, comment #21:

Making the axes invisible -- with axis("off") or set(gca,"visible","off") does not work for me. Only creates a transparent figure without no line or color.

Helios

Helios De Rosario <heliosdr>
Tue 19 Aug 2014 09:32:24 AM UTC, comment #20:

Here is a stackoverflow question with the same problem with Octave 3.8.1.1 on Windows 8 64-bit:
http://stackoverflow.com/questions/23125498/axes-but-no-lines-when-printing-plot-in-octave-for-windows

@sergey: I guess that due to some rounding errors which I'm not able to reproduce in VirtualBox the plotted line is behind the white axes box. To verify this, can you try

t = 0:0.1:6.28318;
plot (t, sin(t));
axis ("off")
print ("-dpngalpha", "figure.png")

I also remember that I had a discussion on IRC with someone how faced the same problem and when he disabled GL2PS_OCCLUSION_CULL is gl2ps-renderer.cc the lines where in the produced eps output but behind the 2 triangles which forms the white axes box.

Andreas Weber <andy1978>
Project Member
Thu 24 Jul 2014 07:57:56 AM UTC, comment #19:

>> print -color -deps test1.eps -debug

epstool command: '%myself%\octave-4.1.0\bin\gs.exe -dQUIET -dNOPAUSE
-dBATCH -dSAFER -sDEVICE=epswrite -sOutputFile=""test1.eps"" -'
fltk-pipeline: '%myself%\octave-4.1.0\bin\gs.exe -dQUIET -dNOPAUSE -
dBATCH -dSAFER -sDEVICE=epswrite -sOutputFile=""test1.eps"" -'

As far as I can see, output of gl2ps is always being piped through ghostscript in Windows. Did I get it right? Do you think that may cause the problem?

sergey plotnikov <nul0m>
Thu 24 Jul 2014 07:36:18 AM UTC, comment #18:

@sergey: You could try to save the raw output of gl2ps whithout piping through ghostscript with

print -color -deps test1.eps

Please try this and see if the lines are missing. (I see you've already done this with aaa.eps)

Then you can try

print -color -deps "-S560,420" test2.eps

Which avoids resizing the fltk window (If you haven't resized it manually) after plotting which could be a reason for timing issues.

+verbatim
HTH, Andy

Andreas Weber <andy1978>
Project Member
Sat 19 Jul 2014 12:22:22 PM UTC, comment #17:

The following might help to understand...

I've rebuilt my 4.1.0+ with gl2ps-renderer.cc reverted to the latest stable version of it and the problem has disappeared.

There are just a couple of differences in that file between branches. Once I have some time I may try different combinations to see what might cause the error.

Are there any simpler way how to test it without remaking + re(cross)compiling all?

sergey plotnikov <nul0m>
Mon 14 Jul 2014 05:57:27 PM UTC, comment #16:

And to be complete...

The code produces correct result on the same system (Win7 x64) with Octave 3.8.1-4 and 3.8.1-5 downloaded from http://mxeoctave.osuv.de/ as well as wtih Octave 3.8.2-rc2 being cross-compiled (using the same MXE-Octave cset).

Ghostscript version in these cases was 9.07 (*x64*), downloaded from http://downloads.ghostscript.com/public/.

sergey plotnikov <nul0m>
Mon 14 Jul 2014 05:31:28 PM UTC, comment #15:

Sorry, Andreas, I was just updating my previous posts where some of these were mentioned. The chart was created in Octave 4.1.0+ cross-compiled using MXE_Octave. Below are all the details:

OS: Win7 x64
Octave: 4.1.0+, cross-compiled on Ubuntu 13.10 from cset df972b9d080a -- "Translate patch property listeners to C++ (bug #42159)".
MXE-Octave: 35404cf378db -- "postgres: update to install libpq.dll correctly ..."
GS: one which is being compiled during MXE-Octave cross-compilation process, the version is 9.07.

Sorry again. I can post any other additional info if needed.

sergey plotnikov <nul0m>
Mon 14 Jul 2014 04:09:48 PM UTC, comment #14:

@sergey: Which Octave and ghostscript version have you used to create aaa.eps? What OS version? Can you add URLs to the downloaded files? Please try to be precise as possible because no developer is able to reproduce this so far.

Andreas Weber <andy1978>
Project Member
Mon 14 Jul 2014 09:58:23 AM UTC, comment #13:

In my case bug is only showing up in recent 4.1.0+. The strange thing is that on 3.8.2-rc2 which was cross-compiled using the same settings there's no such a problem.

Attached is the output for the following code:

>> plot(sin(1:10),'linewidth',2)
>> print -depsc aaa

(file #31713)

sergey plotnikov <nul0m>
Fri 11 Jul 2014 12:02:00 PM UTC, comment #12:

Hi. GS9.07 (32bit) does print the PS file, too (but with the same bug in my machine).

Helios De Rosario <heliosdr>
Fri 11 Jul 2014 11:42:36 AM UTC, comment #11:

Hi Andreas. I have tried same as you:

MXE 3.8.1-4 from http://mxeoctave.osuv.de/
GS 9.09 32 bits (from http://downloads.ghostscript.com/public/gs909w32.exe, since the sourceforge site is not maintained).

I cannot create the ps file, though! (As happened with GS9.14, but not with GS9.06).

See below:

C:\Octave\Octave-3.8.1-4>set PATH=%PATH%;%CD%\bin\;C:\gs\gs9.09\bin

C:\Octave\Octave-3.8.1-4>octave -i --line-editing
GNU Octave, version 3.8.1
Copyright (C) 2014 John W. Eaton and others.
This is free software; see the source code for copying conditions.
There is ABSOLUTELY NO WARRANTY; not even for MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE.  For details, type 'warranty'.

Octave was configured for "i686-w64-mingw32".

Additional information about Octave is available at http://www.octave.org.

Please contribute if you find this software useful.
For more information, visit http://www.octave.org/get-involved.html

Read http://www.octave.org/bugs.html to learn how to submit bug reports.
For information about changes from previous versions, type 'news'.

octave:1> graphics_toolkit fltk
octave:2> plot(1:2, "o-")
octave:3> print("testplot.ps","-debug")
warning: print.m: epstool binary is not available.
Some output formats are not available.
---- begin C:\Users\HEDERO\AppData\Local\Temp\oct-2.ps ----
%!PS-Adobe-3.0
<< /Margins [0 0] /.HWMargins [0 0 0 0] /PageOffset [18 180] >> setpagedevice
%%EOF
----- end C:\Users\HEDERO\AppData\Local\Temp\oct-2.ps -----
Ghostscript command: 'C:\gs\gs9.09\bin\gswin32c.exe -dQUIET -dNOPAUSE -dBATCH -d
SAFER -sDEVICE=pswrite -dLanguageLevel=1 -dEmbedAllFonts=true -dEPSCrop -sPAPERS
IZE=letter -dFIXEDMEDIA -sOutputFile="testplot.ps" C:\Users\HEDERO\AppData\Local
\Temp\oct-2.ps -'
fltk-pipeline: 'C:\gs\gs9.09\bin\gswin32c.exe -dQUIET -dNOPAUSE -dBATCH -dSAFER
-sDEVICE=pswrite -dLanguageLevel=1 -dEmbedAllFonts=true -dEPSCrop -sPAPERSIZE=le
tter -dFIXEDMEDIA -sOutputFile="testplot.ps" C:\Users\HEDERO\AppData\Local\Temp\
oct-2.ps - & rm C:\Users\HEDERO\AppData\Local\Temp\oct-2.ps'
Unknown device: pswrite
Unrecoverable error: undefined in .uninstallpagedevice
Operand stack:
    defaultdevice

Helios De Rosario <heliosdr>
Fri 11 Jul 2014 11:26:22 AM UTC, comment #10:

Yep, that what I wanted to say, since Philip is not able to reproduce this bug it might be just the problem of my cross-compilation.

The latest MXE-Octave is building GS on its own, so I'm using the one which is in Octave's bin folder. And according to "ghostscript.mk" it supposed to be gs9.07. Will check if this is really it.

sergey plotnikov <nul0m>
Fri 11 Jul 2014 11:11:31 AM UTC, comment #9:

I tried this today with MXE 3.8.1-4 from http://mxeoctave.osuv.de/ and gs909w32.exe from http://sourceforge.net/projects/ghostscript/
and can't confirm this bug. The printed files are as expected.

@sergey: Philip also wasn't able to reproduce this with MXE-cross-built binary for Octave-4.1.0+.

As already mentioned gs9.14 can't be used because they removed pswrite.

@sergey and @helios: what exact version of GS are you using? Using the 64bit version needs some more work:
http://wiki.octave.org/Octave_for_Microsoft_Windows#Printing_.28installing_Ghostscript.29

Andreas Weber <andy1978>
Project Member
Thu 10 Jul 2014 11:19:03 PM UTC, comment #8:

I can confirm this bug for the recent MXE-cross-built Octave 4.1.0+ installed on Win7 x64.

May this just be a problem of (cross)compiling, since Philip cannot replicate it?

sergey plotnikov <nul0m>
Sat 14 Jun 2014 07:11:11 AM UTC, comment #7:

pswrite was removed in gs 9.14: http://www.ghostscript.com/doc/current/News.htm. I'm running out of ideas here, sorry

Andreas Weber <andy1978>
Project Member
Fri 13 Jun 2014 12:09:51 PM UTC, comment #6:

Thanks Andreas. Your summary is correct.
I will try in another computer and see.
In the meanwhile, this is the output and file (attached) you suggest.

I first tried with GS 9.14, and printing to ps failed (but other formats gave the result that I mentioned before):

>> plot(1:2,"o-");
>> print("testplot.ps","-debug")
---- begin C:\Users\HEDERO\AppData\Local\Temp\oct-2.ps ----
%!PS-Adobe-3.0
<< /Margins [0 0] /.HWMargins [0 0 0 0] /PageOffset [18 180] >> setpagedevice
%%EOF
----- end C:\Users\HEDERO\AppData\Local\Temp\oct-2.ps -----
Ghostscript command: 'C:\gs\gs9.14\bin\gswin64c.exe -dQUIET -dNOPAUSE -dBATCH -dSAFER -sDEVICE=pswrite -dLanguag
eLevel=1 -dEmbedAllFonts=true -dEPSCrop -sPAPERSIZE=letter -dFIXEDMEDIA -sOutputFile="testplot.ps" C:\Users\HEDE
RO\AppData\Local\Temp\oct-2.ps -'
fltk-pipeline: 'C:\gs\gs9.14\bin\gswin64c.exe -dQUIET -dNOPAUSE -dBATCH -dSAFER -sDEVICE=pswrite -dLanguageLevel
=1 -dEmbedAllFonts=true -dEPSCrop -sPAPERSIZE=letter -dFIXEDMEDIA -sOutputFile="testplot.ps" C:\Users\HEDERO\App
Data\Local\Temp\oct-2.ps - & rm C:\Users\HEDERO\AppData\Local\Temp\oct-2.ps'
Unknown device: pswrite
Unrecoverable error: undefined in .uninstallpagedevice
Operand stack:
    defaultdevice
>>

Then I have tried with a previous version of GS (9.06) and it has generated the PS file, but with the same problem as mentioned before:

>> plot(1:2,"o-");
>> print("testplot.ps","-debug")
---- begin C:\Users\HEDERO\AppData\Local\Temp\oct-2.ps ----
%!PS-Adobe-3.0
<< /Margins [0 0] /.HWMargins [0 0 0 0] /PageOffset [18 180] >> setpagedevice
%%EOF
----- end C:\Users\HEDERO\AppData\Local\Temp\oct-2.ps -----
Ghostscript command: 'C:\gs\gs9.06\bin\gswin32c.exe -dQUIET -dNOPAUSE -dBATCH -dSAFER -sDEVICE=pswrite -dLanguag
eLevel=1 -dEmbedAllFonts=true -dEPSCrop -sPAPERSIZE=letter -dFIXEDMEDIA -sOutputFile="testplot.ps" C:\Users\HEDE
RO\AppData\Local\Temp\oct-2.ps -'
fltk-pipeline: 'C:\gs\gs9.06\bin\gswin32c.exe -dQUIET -dNOPAUSE -dBATCH -dSAFER -sDEVICE=pswrite -dLanguageLevel
=1 -dEmbedAllFonts=true -dEPSCrop -sPAPERSIZE=letter -dFIXEDMEDIA -sOutputFile="testplot.ps" C:\Users\HEDERO\App
Data\Local\Temp\oct-2.ps - & rm C:\Users\HEDERO\AppData\Local\Temp\oct-2.ps'
>>

(file #31542)

Helios De Rosario <heliosdr>
Fri 13 Jun 2014 08:14:24 AM UTC, comment #5:

@Helios: have you been able to isolate the problem?

I want to summarize: You are able to plot (for example
plot(1:2)) with graphics_toolkit("fltk") and you see the line in the figure but when you use print (regardless of the used format) the line is missing in the created file. If you also use markers plot(..."o-") you see the markers and the line in the figure, but not in the file created with print.

Can you install your downloaded Octave, gs, epstool on another computer with different graphic card and driver and try it there?

As a last idea, can you run plot(1:2,"o-"); print("testplot.ps","-debug") and add the output and file here?

Andy

Andreas Weber <andy1978>
Project Member
Wed 11 Jun 2014 07:08:03 AM UTC, comment #4:

It's the same regardless of line width (see attached file)

(file #31537)

Helios De Rosario <heliosdr>
Tue 10 Jun 2014 08:24:18 PM UTC, comment #3:

can you try

plot(randn(10,1), "o-", "linewidth", 5)

Just a wild guess that your graphic card/driver, gl2ps and antialiasing may interfere. -- Andy

Andreas Weber <andy1978>
Project Member
Tue 10 Jun 2014 08:19:25 PM UTC, comment #2:

Yes, the directories added to the path did include the "bin" subdir. Otherwise no image file would actually be created, instead of an incomplete picture.

Helios De Rosario <heliosdr>
Tue 10 Jun 2014 06:07:40 PM UTC, comment #1:

Can't confirm here with MXE-cross-built binary for Octave-4.1.0+, see attached pic.

Did you add the relevant subdirs to the windows PATH (i.e., C:\gs\gs9.14\bin)? (repeat: subdir bin/)
epstool isn't required to make svg plots, Octave complains but it makes the .svg plot anyway.


Philip Nienhuis <philipnienhuis>
Project Member
Tue 10 Jun 2014 02:58:35 PM UTC, original submission:

MXE build downloaded from http://mxeoctave.osuv.de/
GS 9.14 and Epstool 3.08, installed in:
C:\gs\gs9.14
C:\epstool-3.08
Both included in the path before starting Octave

graphics_toolkit fltk
plot(randn(10,1), "o-")
grid on
print -dsvg testplot.svg

The line is not shown in the printed plot.
Markers and grid lines are ok.
It does work with previous versions of Octave (including MXE build of 3.8.0), and it still works when the graphics_toolkit is gnuplot.

The result is the same from the GUI and from the command line interface, and for any graphic format (SVG, EPS, PNG, etc.)

Helios De Rosario <heliosdr>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #33303:  testplot.png added by lrq3000 (29KiB - image/png)
file #32131:  test.eps added by mmx1337 (6KiB - application/postscript)
file #32128:  test123.svg added by mmx1337 (7KiB - image/svg+xml)
file #32129:  test123.eps added by mmx1337 (5KiB - application/postscript)
file #31713:  aaa.eps added by nul0m (5KiB - application/postscript)
file #31542:  testplot.ps added by heliosdr (9KiB - application/postscript - PS file generated with GS9.06)
file #31537:  testplot.svg added by heliosdr (9KiB - image/svg+xml - linewidth = 5)
file #31532:  testplot.png added by philipnienhuis (68KiB - image/png)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by juanpi (Posted a comment)
  • -email is unavailable- added by mycae (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by lrq3000 (Posted a comment)
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by mmx1337 (Posted a comment)
  • -email is unavailable- added by pmanganelli (Posted a comment)
  • -email is unavailable- added by nul0m (Posted a comment)
  • -email is unavailable- added by andy1978 (Posted a comment)
  • -email is unavailable- added by heliosdr (Submitted the item)
  •  

    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 15 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-11-25 rik5 Open/ClosedOpen => Closed
    2015-03-09 rik5 StatusReady For Test => Invalid
    2015-03-09 lrq3000 Attached File- => Added testplot.png, #33303
    2015-02-14 rik5 StatusConfirmed => Ready For Test
    2014-09-25 mtmiller StatusWorks For Me => Confirmed
        SummaryNo lines when printing plot (fltk) => No lines when printing fltk plot with Intel graphics on Windows
    2014-09-25 mtmiller CategoryPlotting => Plotting with OpenGL
    2014-09-18 mmx1337 Attached File- => Added test.eps, #32131
    2014-09-18 mmx1337 Attached File- => Added test123.svg, #32128
        Attached File- => Added test123.eps, #32129
    2014-07-14 nul0m Attached File- => Added aaa.eps, #31713
    2014-06-13 heliosdr Attached File- => Added testplot.ps, #31542
    2014-06-11 heliosdr Attached File- => Added testplot.svg, #31537
    2014-06-10 philipnienhuis Attached File- => Added testplot.png, #31532
        StatusNone => Works For Me

    Back to the top


    Powered by Savane 3.4