fyne-io
Support Software Rendering for X11 by allowing to disable GLX
Checklist
- [X] I have searched the issue tracker for open issues that relate to the same problem, before opening a new one.
- [X] This issue only relates to a single bug. I will open new issues for any other problems.
Describe the bug
I am trying to develop a Fyne application in a devcontainer on Mac OS. The challenge with this is that with the new M1/M2/M3 Macs there is no GPU acceleration in Docker, so their is only the software renderer in MESA available.
When I run my application I get a crash like this:
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
2024/04/11 16:07:51 Fyne error: window creation error
2024/04/11 16:07:51 Cause: APIUnavailable: GLX: OpenGL ES requested but GLX_EXT_create_context_es2_profile is unavailable
2024/04/11 16:07:51 At: /go/pkg/mod/fyne.io/fyne/[email protected]/internal/driver/glfw/driver_notwindows.go:9
with a bit of searching I found that you can give GLFW the window hint GLFW_EGL_CONTEXT_API to disable using GLX API calls, which I think would fix my problem, but I don't see a way to do that within Fyne.
My usecase is sort of esoteric but there are probably other uses of using Fyne with software rendering.
How to reproduce
Here is my Dockerfile:
FROM mcr.microsoft.com/devcontainers/go:1-1.22-bookworm
RUN apt-get update && export DEBIAN_FRONTEND=noninteractive \
&& apt-get -y install --no-install-recommends \
# Install additional packages
libgl1-mesa-dev \
xorg-dev \
libasound2-dev \
x11-apps \
dbus dbus-x11 \
mesa-utils \
&& apt-get autoremove -y && apt-get clean -y && rm -rf /var/lib/apt/lists/*
within that docker container, run a minimal Fyne application and the GUI will not appear.
Screenshots
No response
Example code
func main() {
app := app.New()
win := app.NewWindow("MyApp")
win.ShowAndRun()
}
Fyne version
2.4.4
Go compiler version
1.22
Operating system and version
MacOS host, Debian 11 dev container
Additional Information
No response
The problem seems to be that on ARM we are picking GLES, while we should pick GL for Mac M* hardware when inside a docker container.
I don't know if this is a daft question but why are you running a GUI app in a docker container? All our tooling is designed to build native apps for each platform.
P.s. If you want to build a GUI for docker won't it need to be a Linux app not a macOS app?
Does it help to build with -tags egl? Most apps have switched to EGL from GLX by now on Linux but go-gl (or maybe it is upstream GLFW) still uses GLX by default.
This might also be an effect related to the fact that you might not have all the necessary graphics drivers installed in the Docker container. I do most of my development in a Fedora Toolbox container on Fedora Silverblue and that requires some extra driver packages to be installed for things to work as expected (see https://github.com/containers/toolbox/issues/1023#issuecomment-1072702998)
@andydotxyz:
I don't know if this is a daft question but why are you running a GUI app in a docker container?
Not a daft question, and for the record the project compiles flawlessly on MacOS with just XCode and Go installed. However I'm trying to make a coding screen for interviewees and wanted to make then environment as simple and non-invasive for them to use as possible, so I was hoping to provide a devcontainer they could just checkout and use without having to install a bunch of dependencies on their computers they may not need to use.
In the past I've done this with apps that either don't have GUIs or use the web, but we are a Go shop and I thought this would be a good platform.
As an aside, I tried to use the web target as another work around and downgraded go to 1.19 to use gopherjs's 1.19 beta, but one of the dependencies my project has uses generics. I tried export GOPHERJS_EXPERIMENT=generics then building, but it still gave me problems - maybe the environment variables aren't passed from fyne into gopherjs?
@Jacalz:
Does it help to build with -tags egl?
I get the same result with or without the -tags egl, assuming I'm doing this right:
$ fyne build -tags egl
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
2024/04/12 15:11:48 Fyne error: window creation error
2024/04/12 15:11:48 Cause: APIUnavailable: GLX: OpenGL ES requested but GLX_EXT_create_context_es2_profile is unavailable
2024/04/12 15:11:48 At: /go/pkg/mod/fyne.io/fyne/[email protected]/internal/driver/glfw/driver_notwindows.go:9
I installed libgl1-mesa-glx and mesa-vulkan-drivers in addition to all the other mesa packages I had but that didn't change the output.
I was hoping to provide a devcontainer they could just checkout and use without having to install a bunch of dependencies on their computers they may not need to use.
A fyne app has no runtime dependencies, so hopefully this is not a build issue. If you need to bundle other tools for your interview setup then I guess I can see why you took this path - but a virtual machine would more commonly be used for this sort of setup - and VirtualBox is able to provide the proper graphics context for the runtime.
As an aside, I tried to use the web target as another work around and downgraded go to 1.19 to use gopherjs's 1.19 beta, but one of the dependencies my project has uses generics. I tried export GOPHERJS_EXPERIMENT=generics then building, but it still gave me problems - maybe the environment variables aren't passed from fyne into gopherjs?
You could use the develop branch of Fyne and/or the new tools/cmd/fyne repo/location which no longer uses GopherJS for the web build.
You could use the develop branch of Fyne and/or the new tools/cmd/fyne repo/location which no longer uses GopherJS for the web build.
How would I do this? I tried go get ...@develop but I got a lot of compiler and import errors I wasn't sure how to proceed with.
Never try to go get github.com/fyne-io/fyne/v2. You should still use fyne.io like usual
@Jacalz in that case how do I use the develop branch? Or should I just not try that?
You could use the develop branch of Fyne and/or the new tools/cmd/fyne repo/location which no longer uses GopherJS for the web build.
These two commands ought to work:
go get fyne.io/fyne/v2@develop
go mod tidy
Ah, ok that works, thanks. When I do that I get:
$ fyne serve
../../go/pkg/mod/fyne.io/fyne/[email protected]/app.go:84:16: Pointer not declared by package atomic
error building application: exit status 1
is that something I'm doing wrong or a temporary hiccup with the develop branch?
Sorry, I realize this is veering off topic from the original issue request but it is potentially more directly addressing my primary goal.
Ah, sorry, that's just how you get fyne from the develop branch. You also need to use the new fyne command: https://github.com/fyne-io/tools/blob/main/cmd/fyne/main.go
go install fyne.io/tools/cmd/fyne@main
Thank you @Jacalz ! That got me going and the app works for me now. I have a small problem which is that it loads into a black screen - I think this is because of Chrome's anti-autoplay of audio policy and my app loads ebitengine to play audio, but that's a separate issue.
The specific problem I created this ticket for isn't solved but I have an even better work around, so thank you everyone who chimed in.
This is another +1 for having software rendering. It's a pain to run a Fyne app, only to have it say "you need GLX v1.3", when that version isn't available (and easily upgradable) on your install.
Be careful what you wish for - an unaccelerated app is very much less performant (even web browsers are hardware accelerated now). What sort of computer are you running that does not support GLX? We test on Raspberry Pi and other low power devices like Chrome Book that work great!
What sort of computer are you running that does not support GLX?
As I posted in the initial summary:
I am trying to develop a Fyne application in a devcontainer on Mac OS (running XQuartz). The challenge with this is that with the new M1/M2/M3 Macs there is no GPU acceleration in Docker, so their is only the software renderer in MESA available.
Be careful what you wish for - an unaccelerated app is very much less performant (even web browsers are hardware accelerated now). What sort of computer are you running that does not support GLX? We test on Raspberry Pi and other low power devices like Chrome Book that work great!
The issue in my case is that I am running the LTS versions of Debian/Ubuntu for stability, and the GLX version running is only v1.2. That means anything built against v1.3 won't work on them. Maybe if Fyne used an older version of GLX that is more backwards/forwards compatible, that could be somewhat of a compromise. But I think having software-rendering would better since it just works for anything. And if you really need performance (Many simple GUI apps won't), then you know where to get it.
What sort of computer are you running that does not support GLX?
As I posted in the initial summary:
I am trying to develop a Fyne application in a devcontainer on Mac OS (running XQuartz). The challenge with this is that with the new M1/M2/M3 Macs there is no GPU acceleration in Docker, so their is only the software renderer in MESA available.
Sorry about that, I was kindof asking a mix of people who have got in on this thread.
However. Given that this is a toolkit that works for all platforms is it not reasonable for us to recommend that on macOS you compile the macOS binary instead of a Linux one inside a container?
We are trying to break free from emulation and go on-the-tin for every device, not be constrained by the platforms that try to blur the edges :)
Be careful what you wish for - an unaccelerated app is very much less performant (even web browsers are hardware accelerated now). What sort of computer are you running that does not support GLX? We test on Raspberry Pi and other low power devices like Chrome Book that work great!
The issue in my case is that I am running the LTS versions of Debian/Ubuntu for stability, and the GLX version running is only v1.2. That means anything built against v1.3 won't work on them. Maybe if Fyne used an older version of GLX that is more backwards/forwards compatible, that could be somewhat of a compromise.
This doesn't seem right - we test against LTS Debian all the time. Is it possible that you have compiled locally with a GLX1.3 and then tried to run the binary on an older computer? Our only graphics requirement is the OpenGL API version which is from around 18 years ago...
Sorry about that, I was kindof asking a mix of people who have got in on this thread.
Sure, no problem, I didn't mean it to be snarky, just didn't know if you had seen it
However. Given that this is a toolkit that works for all platforms is it not reasonable for us to recommend that on macOS you compile the macOS binary instead of a Linux one inside a container?
Fair point, but my usecase is verifying my build works on Linux from my Mac.
In my case, I'm using a Fyne-based project as a software engineering coding challenge and was hoping to standardize development across all platform within the devcontainer. I realize that may be a bit niche.
We are trying to break free from emulation and go on-the-tin for every device, not be constrained by the platforms that try to blur the edges :)
Sure, understood, maybe my use-case is too niche. when I filed the ticket I was hoping there was some quick workaround.
In my case, I'm using a Fyne-based project as a software engineering coding challenge and was hoping to standardize development across all platform within the devcontainer. I realize that may be a bit niche.
Part of the point of Fyne (and Go) is that Devcontainers would no longer be needed. Because the apps will work identically everywhere I don't understand the benefit of running it under emulation.
The point is a standardized development environment - it minimizes the setup work required for development. Since this is a coding challenge, it gets shared with a lot of people and I don't want them struggling with setting up their environments, I'd like them to focus on the code itself.
BTW, the devcontainer worked great on both Linux and Windows.
Also, I completely understand the goal - fund is excellent and being able to write once and compile for all platforms is great.
I wonder if the "Windows server" solution works here as well - shipping a software OpenGL renderer into the target system. If the dev container is part of the stack you are managing would that be possible? That way we can list how it can be set up but keep focusing the work we do at "on the tin" installations otherwise we could get caught in exponential growth of systems to support through each emulation / compatibility abstraction that each system can run...
I wonder if the "Windows server" solution works here as well
I'm not familiar with this suggestion - I'm willing to give it a try