bugGNU Octave - Bugs: bug #52266, axis lines not shown in plot window

 
 

bug #52266: axis lines not shown in plot window

Submitter:  Muhali <muhali>
Submitted:  Mon 23 Oct 2017 08:51:57 AM UTC
   
 
Category:  Documentation Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  Works For Me Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Tue 06 Sep 2022 01:50:45 PM UTC, comment #18: 

Closing this old report from 2017. All the tests listed work for me on current Octave out of the box with software and hardware rendering both. If it is still a problem for Octave 8, it can be reopened.

Arun Giridhar <arungiridhar>
Group Member
Thu 26 Oct 2017 05:37:56 AM UTC, comment #17: 

Also setting LIBGL_DRI3_DISABLE=1 seems to solve the problem for me.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Wed 25 Oct 2017 07:06:05 PM UTC, comment #16: 

Software driver works. My point is the axis thing seems to be
a bug that came and will probably disappear with the next mesa/kernel update (but something else will pop-up).
So the documentation (instructions for the users)
has to be more generic and not tied down to this particular bug.

I am more and more inclined to set this option as a default
and have a readme that instructs brave users to try a hardware
driver.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Wed 25 Oct 2017 07:00:38 PM UTC, comment #15: 

@Dmitri: In your case, does using LIBGL_ALWAYS_SOFTWARE fail as well?  Is there no combination of HW or SW rendering that is working for you?  That would be pretty bad.

Rik <rik5>
Group administrator
Wed 25 Oct 2017 06:57:57 PM UTC, comment #14: 

I think it has to be more generic. The thing with this bug is that i used to be able to plot and did not have the issue, and now i have (with 4.2.1). So it must be a mesa driver (or mesa/kernel combo); a new mesa driver will come along and things will change again...

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Wed 25 Oct 2017 06:52:26 PM UTC, comment #13: 

I think the benchmarking is a useful piece of code to have.  When it is fully ready it should become part of the compare_plot_demos.m script so that we can run this before each release to see if plotting or performance has suffered.

However, for this bug report, the issue is how to instruct a user on how to set LIBGL_ALWAYS_SOFTWARE if they find innacurate renderings.  I changed the Category of this bug to Documentation.  I don't know if the new documentation should be in the manual, maybe in Appendix D about Known Bugs?  Or should it be on the wiki?

Seems like there should be a brief explanation of how Octave emits OpenGL instructions, but those instructions have to be interpreted by someone: 1) either a software library, or 2) directly by HW in a graphics card.  Even though Octave emits valid OpenGL code, problems can arise if there are bugs in the implementation of either 1) or 2).

Then, ask the user to run the code


graphics_toolkit qt
plot ([0 1])


and see if the axes lines are visible.  If they aren't, recommend using the environment variable to disable HW acceleration.

Rik <rik5>
Group administrator
Wed 25 Oct 2017 01:36:37 PM UTC, comment #12: 

If it may help I had mofified the plot demo scripts to be able to save and summarize timing data. It is in a very draft state but usable. The visible differences are:

  • timing data are saves together with eventual error/warning message for each plot
  • when compararing 2 states of Octave with html_compare_plot, a summary of timings and differences (based on image correlation) is emitted in an html page.


(file #42257)

Pantxo Diribarne <pantxo>
Group Member
Wed 25 Oct 2017 04:13:06 AM UTC, comment #11: 

I run dump_plot_demos_1 with hardware and with software opengl.
Attached are the timings (first is screen plot time, the second is printing to png). This is on the affected machine.
I also included original diary1.log so one can figure out
which data corresponds to what demo. May be somebody can write a script to extract this data from this log file (I did it manually with search and replaced and do not feel like doing it again).
Surprisingly sometimes llvmpipe is faster than Hw-acceleration,
so on average Hw is about 2+ times faster.
I hope this is of some interest.

Dmitri.

p.s. Machine is amd fx-8350 with amd 6450 graphics card.
Fedora 26 / Mesa 17.2.2
--


(file #42250, file #42251, file #42252)

Dmitri A. Sergatskov <dasergatskov>
Tue 24 Oct 2017 04:03:44 PM UTC, comment #10: 

I don't think it would be bad to set LIBGL_ALWAYS_SOFTWARE=1 permanently.  You would be choosing software over hardware rendering on a permanent basis.  The advantage is that the software-rendering engine is implementing the OpenGL specification more accurately than the hardware-rendering engine.  The disadvantage would be performance.  For most Octave plots, that shouldn't be a big deal, but if you have an application, maybe gaming or possibly CAD, that needs to draw a lot of polygons then it might be a problem.  Of course, you could always arrange to either set LIBGL_ALWAYS_SOFTWARE only before running Octave.  Or you could go the other way and unset the environment variable before running your graphics-intensive software.

Rik <rik5>
Group administrator
Tue 24 Oct 2017 07:44:51 AM UTC, comment #9: 

my results are basically identical to Dmitri's. How useful is it to set LIBGL_ALWAYS_SOFTWARE=1 permanently?

Muhali <muhali>
Mon 23 Oct 2017 11:40:31 PM UTC, comment #8: 

I also noticed that turning grid on will show the axes.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Mon 23 Oct 2017 11:14:41 PM UTC, comment #7: 

@Muhali: Could you try the solution from comment #1?


LIBGL_ALWAYS_SOFTWARE=1 octave
plot ([0 1])


It sure seems like this is a problem of the GL renderer (AMD in Dmitri's case), rather than Octave.

Rik <rik5>
Group administrator
Mon 23 Oct 2017 11:00:23 PM UTC, comment #6: 

Nothing changed.

I tried some demos. On busy plots (where it takes a while to make
all plots) I could see the axes being drawn and then they dissapear (on subsecuent replots). But not all of them, see e.g. attached.

Dmitri.
--




Dmitri A. Sergatskov <dasergatskov>
Mon 23 Oct 2017 10:21:14 PM UTC, comment #5: 

What happens if you do


plot ([0, 1])
set (gcf, 'graphicssmoothing', 'off')
set (gca, 'linewidth', 4)


My guess is you will still have a problem, but at least we can be sure that anti-aliasing is disabled.

Rik <rik5>
Group administrator
Mon 23 Oct 2017 05:18:39 PM UTC, comment #4: 

I also switched to Xorg from Wayland and it did NOT make a difference.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Mon 23 Oct 2017 05:12:37 PM UTC, comment #3: 

I had this issue with antialiasing (but not on this particular
computer). This is something else, but I think it is OS related
(new mesa, Wayland, Qt5)...
Attached is the screenshot of Plot(1:3) with



set(0, 'DefaultLineLinewidth', 9)
set(0, 'DefaultAxesLinewidth', 9)


Dmitri.
--



Dmitri A. Sergatskov <dasergatskov>
Mon 23 Oct 2017 04:56:44 PM UTC, comment #2: 

Works for me.  This is with Qt 5.6.1.

This could be a HW or SW issue since OpenGL is often hardware-accelerated (HW), but when it isn't the version of your software-rendering library can make a difference.

What happens if you change the linewidth from 0.5 to 1.0?


plot ([0 1])
set (gca, 'linewidth', 1)


Also, what happens if you use the mouse to change the window size?  Are there times when the lines are visible and times when they are not?  That sometimes happens with fractional linewidths.

Rik <rik5>
Group administrator
Mon 23 Oct 2017 03:55:27 PM UTC, comment #1: 

I have this problem on one of my computers (amd graphics card; Fedora 26, Qt 5.7.1, Wayland). The problem gets "solved" by
setting LIBGL_ALWAYS_SOFTWARE. E.g.:


LIBGL_ALWAYS_SOFTWARE=1 octave


Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Mon 23 Oct 2017 08:51:57 AM UTC, original submission:  

by doing

plot([0 1])

I don't see the axis line, only the ticks in the plot window; printing works, however. This happens both with the stable and dev version, using Arch Linux. Figure is attached.

Muhali <muhali>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #42257:  timings.patch added by pantxo (9KiB - text/x-patch)
file #42250:  software.dat added by dasergatskov (4KiB - application/octet-stream)
file #42251:  diary1.log added by dasergatskov (11KiB - text/x-log)
file #42252:  hardware.dat added by dasergatskov (4KiB - 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 arungiridhar (Posted a comment)
  • -email is unavailable- added by pantxo (Updated the item)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by dasergatskov (Posted a comment)
  • -email is unavailable- added by muhali (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 10 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-09-06 arungiridhar Open/ClosedOpen Closed
    2017-10-25 rik5 CategoryPlotting with OpenGL Documentation
    2017-10-25 pantxo Attached File- Added timings.patch, #42257
    2017-10-25 dasergatskov Attached File- Added software.dat, #42250
        Attached File- Added diary1.log, #42251
        Attached File- Added hardware.dat, #42252
    2017-10-23 dasergatskov Attached File- Added Screenshot_from_2017-10-23_17-54-04.png, #42245
    2017-10-23 dasergatskov Attached File- Added Screenshot_from_2017-10-23_12-05-31.png, #42239
    2017-10-23 rik5 StatusNone Works For Me
    2017-10-23 muhali Attached File- Added Screenshot from 2017-10-23 10-44-23.png, #42235

    Back to the top

    Powered by Savane 3.13-3230.
    Corresponding source code