Wed 08 Nov 2017 09:38:34 AM UTC, comment #10:
I think this report can be closed as fixed: since 2D figures are now rendered without depth test it can safely be assumed that if such bug happens it can only be an upstream driver issue.
|
Mon 29 Feb 2016 07:37:46 PM UTC, comment #9:
If I understand correctly, bug #47191 is about a failure to print correctly. In other words, the onscreen display produced by OpenGL is correct, but gl2ps fails to translate that correctly to PostScript or PDF or SVG.
This bug is about actual onscreen display, i.e., OpenGL is not working correctly.
I think the next step is to try disabling HW OpenGl rendering on the machine involved and see if that fixes the issue. I believe this can be done by adding
to the driver configuration section of xorg.conf.
This page is about using an Intel GPU (https://wiki.archlinux.org/index.php/Intel_Graphics), but the principles are the same if you have an Nvidia graphics card or something else.
|
Mon 29 Feb 2016 09:09:00 AM UTC, comment #8:
There was a somewhat similar bug report here (http://savannah.gnu.org/bugs/?47191), where z-level issues can be triggered by contourf command. (EDIT)
|
Mon 29 Feb 2016 09:07:03 AM UTC, comment #7:
There was a somewhat similar bug report here (http://savannah.gnu.org/bugs/?47217), where z-level issues can be triggered by contourf command.
|
Sat 27 Feb 2016 02:48:58 AM UTC, comment #6:
It's probably the actual OpenGL driver. Maybe you could disable HW rendering temporarily and use SW rendering to see if that fixes it?
I'm attaching a screen snapshot of a good example of isosurface. The black lines of the polygons are always distinct.
Re-titling to remove FLTK since this is generic to OpenGL.
(file #36485)
|
Sat 27 Feb 2016 02:35:31 AM UTC, comment #5:
I got FLTK 1.3.3 working (I had recompiled it, but not reinstalled it), and it gives the same problem.
|
Sat 27 Feb 2016 01:18:12 AM UTC, comment #4:
It fails for Qt as well. I should have checked...
You are right that playing with patch is bad because it is used by other functions. My first plan was to change the depth of imagesc, but I couldn't see where that is set. Do you know where?
Also, are the Z-levels documented somewhere? I can imagine that it would have been a nightmare getting them all co-ordinated.
I'm not sure what the isosurface is supposed to look like. Is the problem that some lines are thinner than other, or are some actually missing?
I've tried compiling with FLTK 1.3.3, but get linker errors:
despite configuring with CFLAGS=-fPIC CXXFLAGS=-fPIC. (I'm not asking you to solve this; just keeping you informed.)
|
Fri 26 Feb 2016 08:00:15 PM UTC, comment #3:
This may very well come down to different software versions and also different HW drivers and their support for OpenGL: neither of which is specifically an Octave problem.
Does the plot work if you use the Qt toolkit and its interface to OpenGL?
I fiddled quite a bit with the Z-level offsets in order to get the widest variety of plots to work correctly. It was no fun so I am reluctant to do it again.
For an example of what I mean, I applied your patch and then ran 'demo isosurface'. See the attached plot and you can see that the lines of the various patch objects in the isosurface are partially obscured. This doesn't happen for me as things stand.
(file #36478)
|
Thu 25 Feb 2016 10:07:00 PM UTC, comment #2:
I have fltk 1.3 on Linux Mint Debian Edition with MATE, and get the attached figure.
(file #36467)
|
Thu 25 Feb 2016 05:11:52 AM UTC, comment #1:
This already works for me. Perhaps there is a difference in your local FLTK installation? I have version 1.3.3 and this is on Kubuntu 15.10. See the attached png which looks correct.
(file #36454)
|
Mon 22 Feb 2016 04:52:59 AM UTC, original submission:
Typing
will produce the outline of a patch at the stated coordinates, but inside the patch will still show the random pixels from imagesc.
The reason is that the patch body is deliberately pushed deeper in the Z-buffer's (not the patch's) Z coordinate so that it doesn't overwrite the patch edge. However, it seems that this pushes it behind the imagesc data. I haven't found where that is set, so I can't confirm its Z-buffer location.
Reducing the offset seems to work. I'll submit a changeset once I have the bug number.
|