Re: mxe-octave status

[Philip Nienhuis]

John W. Eaton wrote:
> On 10/20/2017 06:00 PM, John W. Eaton wrote:
> > On 10/20/2017 04:28 PM, Philip Nienhuis wrote:
> >
> > > Ah, I see I misunderstood; you mean that mesa version provokes a
> > > segfault.
> > > (Sorry for not following the whole issue in detail - which relates to
> > > not having hit the issue with older system opengl32.dll libs yet.)
> >
> > No, the mesa version works fine for me.  It's when I've built the qt5
> > version with mesa and then I attempt to use the system opengl32.dll
> > instead.  As far as I know, this should work since the API should be
> > the same.  It's supposed to be a "drop-in replacement"
>
> It looks like the problem that I've experienced is due to the system
> opengl implementation that I have with a Windows 7 installation inside
> virtualbox.  When I tried the same Octave installer on a Windows 10
> system running on real hardware with Intel graphics, it worked fine with
> the system opengl and the mesa version.
>
> This is the info I get from __opengl_info__ on the virtual box system
> (using Octave 4.2.1):
>
>   version    = 1.1.0
>   vendor     = Microsoft Corporation
>   renderer   = GDI Generic
>   extensions =
>     GL_WIN_swap_hint
>     GL_EXT_bgra
>     GL_EXT_paletted_texture

That looks just like the info I got on my (older) PCs at work (using an 
Octave-4.3.0+ from early September) that run Windows 7 Enterprise 64bit.

On those PCs newest Octave-4.3.0+ crashes when invoking graphics functions.

In fact this is the basic Windows-supplied software renderer. It is 
often used by default with older Intel graphics HW. Reading up about 
this I get to vaguely suspect that several bug reports we have about 
failing graphics on Intel HW, are in fact related to this default 
Windows renderer.
Maybe if the mesa-based opengl32.dll does a better job, (some of) those 
old bugs might be solved as well. (yes, speculation)

> so maybe this is insufficient for the qt5 QOpenGLWidget?  Or there is
> just a bug that could be fixed.  Either way, it appears that with the
> mesa opengl32.dll we now have a way to too avoid these problems.

It appears your situation is similar to mine. On my newer systems OpenGL 
is probably at 3.3.0 (anyway high enough), while on older systems OpenGL 
is too old or is provided by the default Windows driver; it's on those 
older systems where problems occur.

> I don't know that we need to detect and repair the problem
> automatically, but we should probably at least have a configuration
> option that arranges for Octave to use the mesa opengl library to do
> software rendering.

Maybe some tool in NSIS can detect the OpenGL version? Or "we" (I can't, 
sorry) can build one ourselves and try to use it in the installer. More 
info here:
https://stackoverflow.com/questions/126028/how-to-write-an-installer-that-checks-for-opengl-support

Philip