Re: mxe-octave status

[PhilipNienhuis]

PhilipNienhuis wrote
> 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)

Indeed, e.g. bug #47337 is solved with the mesa-based opengl32.dll. Nice!
Switching back to the system driver (at opengl v. 3.3.0) brings back the
bug.

So maybe my suggestion in other posts here to test for up-to-date system
opengl32.dll and switch to that during installation needs more thought.

Philip




--
Sent from: http://octave.1599824.n4.nabble.com/Octave-Maintainers-f1638794.html