Fyne doesn't work on Windows 7 VM or remote server

[virtuald]

Fyne looks awesome, and works great out of the box on my mac. I tried to cross-compile for Windows from my mac, and that generates an exe. So far, so good:

GOOS=windows GOARCH=386 CGO_ENABLED=1 CC=$(which i686-w64-mingw32-gcc) go build

Unfortunately, when I run it on my Windows VM (a Windows 7 VirtualBox VM downloaded from Modern.IE), it gives me the following error that others seem to have.

C:\Users\IEUser\Desktop>fynedemo.exe
2019/08/22 15:22:52 Fyne error:  window creation error
2019/08/22 15:22:52   Cause: APIUnavailable: WGL: The driver does not appear to support OpenGL
2019/08/22 15:22:52   At: /Users/virtuald/go/src/fynedemo/vendor/fyne.io/fyne/internal/driver/gl/window.go:999
panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xc0000005 code=0x0 addr=0x2c pc=0x578d8d]

goroutine 1 [running, locked to thread]:
fynedemo/vendor/fyne.io/fyne/internal/driver/gl.(*window).SetContent(0x0, 0x905760, 0x12456120)
        /Users/virtuald/go/src/fynedemo/vendor/fyne.io/fyne/internal/driver/gl/window.go:361 +0x1d
main.main()
        /Users/virtuald/go/src/fynedemo/main.go:12 +0x1ce

I was hoping that this would 'just work' on a bare Windows installation, but that doesn't seem to be the case. Is this configuration supported? What am I missing?

[andydotxyz]

The virtual machine would need to emulate a graphics card with OpenGL support and you would need the appropriate drivers installed.

Virtualisation isn’t something we have looked at but there is no reason that version of Windows wouldn’t work and the file you compiled should work fine :)

[virtuald]

Hm. I downloaded the GLView program and it seems that OpenGL is installed, but the version is 1.1. It seems that's the latest version that MS bundled with the OS. It would probably be good to put this in the documentation somewhere.

It appears there's a software-only Mesa renderer for Windows. I downloaded a prebuilt binary from https://github.com/pal1000/mesa-dist-win/releases, and hello world works now. Might also be a useful thing to put in the documentation?

[andydotxyz]

Thanks for the extra information. We require OpenGL 2.0 or later (yes this should be in the documentation). That was released in April 2004 so we had assumed most drivers would have good support for this by now...

As far as I am aware the Windows operating system does not actually ship the OpenGL implementation but it sits within the graphics driver. Can you please share what virtual machine you are using? (i.e. VMWare, VirtualBox etc) and which version with which graphics options turned on?

We would like to avoid pointing people to a software mesa where possible as we want to provide good performance :)

[virtuald]

I'm using a Windows 7 VirtualBox VM that I downloaded from Microsoft's Modern.IE page: https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/ , so you can download it too if you want to test with it. :)

It appears to have the generic 'VirtualBox Graphics Adapter'.

After researching a little last night, I think you're right that Windows does not ship with OpenGL, and that it's up to the graphics driver to provide it. However, if you don't have a fancy graphics driver (eg, on a VM, or when using Remote Desktop), then you won't have OpenGL available to you, which means any Fyne app will just crash without much warning to a user.

FWIW, my primary interest is having an easy to use cross-platform UI framework that I can use from golang that doesn't require me to jump through a bunch of hoops to use it. Because the sorts of things I'm looking to do are just 'normal' UI things (buttons, text, forms, etc), performance isn't really that important to me -- it's more important that I can hand a binary to an end user and it'll 'just work' without them having to do much work (which is one of the reasons I like golang for cross-platform development!).

The basic fyne_demo command that comes with fyne performs without any noticeable stutter/etc problems using the software renderer.

[virtuald]

For example, the software renderer might help out #191, #386, #409, .. I'm sure others too.

[andydotxyz]

Thanks. Yes it seems you need 3.0 of VirtualBox to add OpenGL 2.0 which we currently require. Fyne is designed to work out of the box on all computers so your expectations are spot on! In 1.2 we are adding support for GLES which means we can add RaspberryPi as well as iOS and Android support as well.

There is a software driver in development also that is designed to enable the Go playground to provide previews and also a richer testing framework but it was never intended to work as a full driver due to concerns over performance. With a reasonable amount of work it is technically possible to extend this to provide a "fallback driver" but I don't know if this makes sense strategically?

[danlester]

Just to confirm I also encounter the same problem as @virtuald using VirtualBox with a Windows 10 image. The Mesa software fixed the issue, but of course you don't want to have to troubleshoot this with regular users.

I think it is possible to argue that virtual machines are unlikely to be used by end users, but remote desktop is a definite possibility.

I personally think that a fallback driver, even with poor performance, is better than just seeing nothing happen.

It doesn't sound like you think GLES support will fix the scenarios described in this issue on its own.

Thank you for your hard work.

[virtuald]

An alternative to seeing nothing happen is to pop up a dialog box (using native message box stuff?) saying that OpenGL isn't available and "go to some link" to figure out what to do, which could tell them how to install mesa? Showing a panic on the console isn't a good fit for non-technical users, as they'll be more likely to just double click an app to run it, so they won't see the error message.

[andydotxyz]

I agree with the idea of better messaging when this happens. Pointing folk to a software Mesa driver could be a good idea. Falling back to a software driver is a possibility in the future but is a huge amount of work for these corner cases.

[lucor]

I also encounter the same problem as @danlester using VirtualBox 6.0 with a Windows 10 image. By default the 3D acceleration is disabled, enabling it allowed to run the fyne_demo app correctly. Below the settings that worked for me:

• Settings -> Display -> Screen
  • Graphics controller: VBoxSVGA
  • Acceleration: Enable 3D acceleration

[glycerine]

Similar error here. On Windows 2012 on a Xen virtual machine over Remote Desktop Protocol (RDP), which is typically going to need ANGLE / GLES support DLL because the RDP means the windowing system will ignore the read of the remote hardware. However I thought that GLES support was in from fyne 1.2, so maybe I just need to know how to activate it?

~/go/src/fyne.io/fyne/cmd/fyne_demo
$ go build
^[]0;~/go/src/fyne.io/fyne/cmd/fyne_demo^G
Administrator@JasonAten-Custo ~/go/src/fyne.io/fyne/cmd/fyne_demo
$ ls
data  fyne_demo.exe  main.go  screens
^[]0;~/go/src/fyne.io/fyne/cmd/fyne_demo^G
Administrator@JasonAten-Custo ~/go/src/fyne.io/fyne/cmd/fyne_demo
$ ./fyne_demo.exe
2020/05/31 14:27:47 Fyne error:  window creation error
2020/05/31 14:27:47   Cause: APIUnavailable: WGL: The driver does not appear to support OpenGL
2020/05/31 14:27:47   At: C:/Users/Administrator/go/src/fyne.io/fyne/internal/driver/glfw/window.go:1075
panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xc0000005 code=0x0 addr=0x0 pc=0x72f129]

goroutine 1 [running, locked to thread]:
fyne.io/fyne/internal/driver/glfw.(*window).SetMainMenu(0x0, 0xc0001261a0)
        C:/Users/Administrator/go/src/fyne.io/fyne/internal/driver/glfw/window.go:234 +0x29
main.main()
        C:/Users/Administrator/go/src/fyne.io/fyne/cmd/fyne_demo/main.go:66 +0x42a
^[]0;~/go/src/fyne.io/fyne/cmd/fyne_demo^G
A ~/go/src/fyne.io/fyne/cmd/fyne_demo
$ git log|head
commit 540f1dfcb4e80c8804e21ceb70345fcf5d787b1b
Author: Josias <63474705+justjosias@users.noreply.github.com>
Date:   Sat May 30 16:16:54 2020 +0300

[andydotxyz]

If you want to force it to compile for GLES instead you can use go build -tags gles . - we mostly auto-detect but this will override that.

I would have thought that you would need a DLL loaded to support either of these types of OpenGL though - let me know how it goes.

[glycerine]

yeah, I have the ANGLE and other DLLs in the directory... but it doesn't seem to notice and use them, so same crash as above. Is there code to load the DLLs that I can activate?

Jason

On Jun 1, 2020, at 6:54 AM, Andy Williams notifications@github.com wrote:

 If you want to force it to compile for GLES instead you can use go build -tags gles . - we mostly auto-detect but this will override that.

I would have thought that you would need a DLL loaded to support either of these types of OpenGL though - let me know how it goes.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[andydotxyz]

I think I was getting OpenGL DLLs confused sorry. The drop-in replacement is Mesa3D I think - that supports being dropped into the current directory at runtime. The ANGLE project seems to require building with their SDK specifically, so is possibly more related to #911?

[jiftle]

VBox 6.1 , Virtual OS is win7.

By default the 3D acceleration is disabled, enabling it allowed to run the fyne_demo app correctly. Below the settings that worked for me:

Settings -> Display -> Screen
    Graphics controller: VBoxSVGA
    Acceleration: Enable 3D acceleration

thanks for Lucor.