Better error reporting / handling when OpenGL is not available

[andydotxyz]

When a Fyne app crashes because it could not create a window this is normally due to a driver issues.
The OS or other dependency is not working.
We should report this better, so developers know what to do or where to report it.
Or to update their drivers etc?

Is it possible to construct a solution with the existing API?

The panics can get pasted here, but we have to interpret the data and often the developer could have solved it themselves.

Describe the solution you'd like to see:

Catch the panic and log the error with suggested fix/next steps and cleanly exit

[Lewiscowles1986]

So are #2373 and #2697 examples of this?

Why does Fyne require GPU acceleration? It seems outside of the stated goals of Fyne

Fyne is an easy-to-use UI toolkit and app API written in Go. It is designed to build applications that run on desktop and mobile devices with a single codebase.

[andydotxyz]

So are #2373 and #2697 examples of this?

Yes

Why does Fyne require GPU acceleration? It seems outside of the stated goals of Fyne

It doesn't stricly speaking require acceleration, but it does require an OpenGL API so that we can use the same code for many platforms.
A VM will not expose OpenGL without the "3D acceleration" setting turned on, but they are not strictly the same thing, there are software drivers that provide OpenGL too.

There are discussions about using OS native APIs for drawing graphics but as we currently support about 7 OS that is clearly a lot more work than is required with the current infrastructure.

[kheyse-oqton]

We want to add our vote to this ticket.
We want to use the fyne library to build an executable that will go to customers.
Before release, we had one machine that did not run the executable; it just quit after launch. Moreover it did not produce output in the windows event viewer (as far as we found) nor in the terminal when launching the application from the prompt. It took several builds with custom compile flags (fyne-cross) before we could diagnose the problem.
If a customer would have encountered this problem, we would in no way have been able to provide support or find the cause of the problem.
Currently there's not even a way for the developer themselves to catch this problem in the code because there's no error return value or a panic triggered by ShowAndRun().

If something goes wrong with an app, it should at least alert the user and preferably provide useful information as to the cause of the problem.

[Bluebugs]

@kheyse-oqton and anyone interested here, I have been thinking of a few ways to solve this problem and was wondering what was your opinion on the following possibility:

• A native windows dialog popup with an error message and the application force quit when no GL is found.
• Include a static build of mesa with software fallback in the binary (increase binary size, but provide a slow working solution for the no gpu case)

(I am ruling out providing a software backend at the moment, as that is a lot of work to get it to a useful state).

[Jacalz]

I’m in favour of the first option. Statically linking mesa is, as you say, going to make binaries even bigger and add more complexity to the building. The less C-deps the better in my opinion.

[kheyse-oqton]

First option would definitely be an improvement!

[Bluebugs]

Thanks to https://github.com/rodrigocfd/windigo, it shouldn't be very hard to get a MessageBox going when we fail to initialize GL.

For reference, extract from windigo, under MIT license. First get a pointer to MessageBox address:

user32 = syscall.NewLazyDLL("user32.dll")
MessageBox                    = user32.NewProc("MessageBoxW")

With that it is possible to trigger a MessageBox with the following function:

https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-messageboxw
// 📑 https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-messageboxw
func (hWnd HWND) MessageBox(text, caption string, uType co.MB) co.ID {
	ret, _, err := syscall.Syscall6(proc.MessageBox.Addr(), 4,
		uintptr(hWnd), uintptr(unsafe.Pointer(Str.ToNativePtr(text))),
		uintptr(unsafe.Pointer(Str.ToNativePtr(caption))), uintptr(uType),
		0, 0)
	if ret == 0 {
		panic(errco.ERROR(err))
	}
	return co.ID(ret)
}

[andydotxyz]

Looks pretty lightweight - but I don't think it's made a release yet, so tread with caution?

[Bluebugs]

@andydotxyz I was not intending to include them as dependency. The code necessary is just the code pasted above, so can be integrated directly in our code.

[andydotxyz]

@andydotxyz I was not intending to include them as dependency. The code necessary is just the code pasted above, so can be integrated directly in our code.

Oh, haha I see. Perfect :)

[Bluebugs]

I have been trying to figure out a way to test without a GPU, but none of my Windows computer can run a Windows in a VM to a point where I can test this. If anyone here would be able to check https://github.com/fyne-io/fyne/tree/feature/graceful-failure-windows-gl . It should now display a MessageBox when there is no GPU available.

[andydotxyz]

Thanks @Bluebugs here is it working on my WIndows VM with the GPU turned off...

[Bluebugs]

This will be in the next 2.2 release :-) And can already be tested with develop.