I filed bug #52260 for the issue I am seeing.

I am using Ubuntu 17.10 on an x11 session with Qt5 version 5.9.1.
In the config.h, I see the following:

/* Define to 1 if you have the <QGLWidget> header file. */
#define HAVE_QGLWIDGET 1
 [snip]
/* Define to 1 if you have the <QOpenGLWidget> header file. */
#define HAVE_QOPENGLWIDGET 1

Does that mean I am using QOpenGLWidget?

Plotting with Qt5 didn't work for me either (unless I set LIBGL_ALWAYS_SOFTWARE=1). That has improved with a recent tip (hg id 8e034cb195f1). That is, the figures no longer appear black even without that switch.

However, the axes grids are rendered upside down on screen. When printing "demo light 1", I see the following:

>> print (1, "demo_light_1_qt5_print.png")
context mismatch in svga_sampler_view_destroy
context mismatch in svga_sampler_view_destroy

Nothing upside down here.

Both on-screen and print results are attached.

With "LIBGL_ALWAYS_SOFTWARE=1 ./run-octave", the figure renders correctly.

It seems to me that something needs fixing, but I don't know whether it's a Mesa problem or a Qt problem.

I've found other problems when building with Qt 5 that seem to me like regressions from Qt 4, but I don't know where to pursue them. It will be a shame if users get a bad Octave experience when systems start to move to Wayland and drop Qt 4 support. We are continuing to build Octave with Qt 4 in Debian as long as things with Qt 5 and Mesa remain fragile.

It still fails occasionally for me even when I set LIBGL_ALWAYS_SOFTWARE=1.

OK.  Thanks for checking.

Mike:  Could you test the patch I posted?  You may have to experiment with the delay time.

Also, for the record, here is the output from glxinfo -B on my system:

zbox:44> glxinfo -B
name of display: :0
display: :0  screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: Intel Open Source Technology Center (0x8086)
    Device: Mesa DRI Intel(R) HD Graphics 400 (Braswell)  (0x22b1)
    Version: 13.0.6
    Accelerated: yes
    Video memory: 1536MB
    Unified memory: yes
    Preferred profile: core (0x1)
    Max core profile version: 4.5
    Max compat profile version: 3.0
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.1
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) HD Graphics 400 (Braswell)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 13.0.6
OpenGL core profile shading language version string: 4.50
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile

OpenGL version string: 3.0 Mesa 13.0.6
OpenGL shading language version string: 1.30
OpenGL context flags: (none)

OpenGL ES profile version string: OpenGL ES 3.1 Mesa 13.0.6
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10

I also see the problem with qt5 and can confirm that resizing the window makes the plot appear.

If I run Octave, attach gdb to the octave-gui process, set a breakpoint in the QtHandles::Container::resizeEvent function and then execute "sombrero" at the octave prompt, execution stops in the resizeEvent function and the figure is properly displayed when I continue execution.  If I delete the breakpoint or type "continue" for gdb prior to executing "sombrero", then the plot doesn't appear properly.

To me, this suggests some kind of timing or threading issue.  And if I make the attached change (inserting a delay in the QtHandles::Container::resizeEvent function), it seems the plot will appear correctly given a sufficient delay.  On my system, a delay of 0.2 seconds appears to be sufficient to make the plot always appear correctly.  With a smaller delay the plot is sometimes correct and sometimes not.  Oddly, it seems to fail more often if the cursor is in the plot window when it is drawn.

I'm not saying that a delay is the right fix, only that this behavior points to some kind of timing issue.  If so, then maybe there is something we can do to avoid the problem?


(file #41192)

I did switch to Intel graphycs and it works fine.

 glxinfo -B
name of display: :1
display: :1  screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: Intel Open Source Technology Center (0x8086)
    Device: Mesa DRI Intel(R) Sandybridge Desktop  (0x122)
    Version: 17.1.4
    Accelerated: yes
    Video memory: 1536MB
    Unified memory: yes
    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: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Sandybridge Desktop
OpenGL core profile version string: 3.3 (Core Profile) Mesa 17.1.4
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile

OpenGL version string: 3.0 Mesa 17.1.4
OpenGL shading language version string: 1.30
OpenGL context flags: (none)

OpenGL ES profile version string: OpenGL ES 3.0 Mesa 17.1.4
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00

uname -a
Linux i7 4.11.9-300.fc26.x86_64 #1 SMP Wed Jul 5 16:21:56 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

cat /proc/cpuinfo

processor        : 0
vendor_id        : GenuineIntel
cpu family        : 6
model                : 42
model name        : Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz
...

FYI.

Dmitri.
--

Dmitry, you're a genius! Not sure what this command does but my plots are working. This should maybe be the default flag to use to run octave.

LIBGL_ALWAYS_SOFTWARE=1 octave

However, the plot does not show up until I resize the plot window. This is very annoying. So I would say its still a bit buggy.

I'm not sure about arch linux, but I've almost always compiled octave using qt4 in the past on ubuntu. And I do remember the configuration options showing qt5 as an option. I didn't even know that octave was built using qt5 in Arch Linux.

Harish - does Arch give you the option of building Octave against either Qt 4 or Qt 5?

Dmitri - which Qt versions have functional plotting for you in a Xwayland session?

I get the following when I run glxinfo -B

name of display: :0
display: :0  screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: Intel Open Source Technology Center (0x8086)
    Device: Mesa DRI Intel(R) HD Graphics 5500 (Broadwell GT2)  (0x1616)
    Version: 17.1.4
    Accelerated: yes
    Video memory: 3072MB
    Unified memory: yes
    Preferred profile: core (0x1)
    Max core profile version: 4.5
    Max compat profile version: 3.0
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.1
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) HD Graphics 5500 (Broadwell GT2)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 17.1.4
OpenGL core profile shading language version string: 4.50
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile

OpenGL version string: 3.0 Mesa 17.1.4
OpenGL shading language version string: 1.30
OpenGL context flags: (none)

OpenGL ES profile version string: OpenGL ES 3.1 Mesa 17.1.4
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10

Is it really a hardware driver issue even though the qt plot stuff works when logged in using XOrg?

Is it a graphics hardware or driver issue if Octave's OpenGL rendering works perfectly under fltk but not under the Qt OpenGL-based qt toolkit? Both are using the same underlying rendering code.

I can confirm this here. Only the qt graphics_toolkit is affected. If you use graphics_toolkit fltk, plots seem to work fine.