Thank you very much for the bisection! I think we need ~eliasnaur's input on this one.

Thank you for your report. Please clarify:

• How much memory?
• Does the memory use stabilize or keep growing?
• Does the problem reproduce by running the example locally? (e.g. "go run gioui.org/example/kitchen")

CC ~whereswaldon in case this is a text layout cache issue.

can you accept that change? Chris you mentioned that disabled widgets may be waiting for some external event to enable itself. In that case, perhaps app.Window.Invalidate is a better fit?

I do not think app.Window.Invalidate is a solution here. It means that all widget code must suddenly have access to a reference to the containing window, when that was previously not a constraint. Additionally, there are two other factors that occur to me:

1. While animation was the motivating reason for allowing command execution, it isn't the only command. There may be many valid uses of commands (in the absence of user input), and there is no analog to app.Window.Invalidate for commands in general.
2. app.Window.Invalidate is a less efficient and less flexible mechanism for orchestrating animation. It takes a less direct codepath to trigger a new frame, and it doesn't allow you to schedule a frame at a particular future time, instead generating one immediately. For animations that should trigger in (say) 1 second, you're making sure a widget has to wastefully generate 60 frames in order to reach the one frame it cares about.

I think the conversion of Context.Source into a method makes sense as a solution. More generally, I still think the semantics of "disabled" on a context should specifically mean "cannot receive input from user", not "cannot interact with any Gio subsystems". Commands are logically quite similar to making method calls on Gio internals, and should be available to widget implementations regardless of the availability of user input.

I'm afraid you'll have to do your own research. All I can say is that windows does not ship a compatible OpenGL driver itself. You essentially rely upon the graphics hardware driver vendor to supply an OpenGL implementation. Plenty of people have funky driver installation situations which could result in no valid OpenGL drivers, or in finding a bad implementation earlier in %PATH% than a good one. YMMV.

Only if the user's Windows system shipped with a supported Desktop OpenGL driver though, which isn't strictly guaranteed on Windows. You'd be opening yourself up to the risk of your app not starting on systems without an OpenGL implementation. Also, OpenGL drivers tend to get less love by graphics vendors on Windows, so they may be buggy or poorly optimized. That's essentially the reason that it's disabled right now. It's not reliable unless you guarantee a good implementation of the API is available, and the best way to do that on Windows is to either use DirectX or use OpenGL ES with ANGLE (which will ultimately use DirectX under the hood).

I think it would be reasonable to allow the use of OpenGL on Windows, but it isn't without downsides.

ANGLE is certainly a pain. I can understand wanting to avoid it. We've been talking about allowing desktop OpenGL more generally in #639, and we could explore enabling it for both Linux and Windows.

Since it's gl.Init failing, I'd guess that at runtime it's failing to discover/bind the OpenGL function pointers that it needs. That could be an issue with your system OpenGL implementation, or it could be a dynamic library path problem.

I'd recommend stepping through the failure in a debugger like delve to check where exactly it fails. If it is failing to bind function pointers, then investigate the OpenGL version you have and make sure it's compatible with the one you're trying to use in your application. Also check that your DLLs for OpenGL are in your %PATH% so that they are loaded correctly.

If you can't get your system OpenGL to work, you could also look into using ANGLE, which provides OpenGL ES on basically every platform.

Hmm, so GLSL 150 corresponds to OpenGL 3.2. Could we do a simple version test and enable the OpenGL renderer if we have at least OpenGL 3.2, or is that too much overhead?

~eliasnaur do you recall the reason for that Chesterton's Fence? Why did we only enable desktop OpenGL on macOS?

@diamondburned reported this crash via slack:

panic: shader compilation failed: 0:1(1): error: syntax error, unexpected end of file
	

goroutine 1 [running, locked to thread]:
gioui.org/gpu.newBlitter({0x7b9520, 0xc0004eec08})
	/home/chris/Code/go/pkg/mod/gioui.org@v0.8.0/gpu/gpu.go:553 +0x425
gioui.org/gpu.newRenderer({0x7b9520, 0xc0004eec08})
	/home/chris/Code/go/pkg/mod/gioui.org@v0.8.0/gpu/gpu.go:506 +0x25
gioui.org/gpu.(*gpu).init(...)
	/home/chris/Code/go/pkg/mod/gioui.org@v0.8.0/gpu/gpu.go:367
gioui.org/gpu.newGPU({0x7b9520, 0xc0004eec08})
	/home/chris/Code/go/pkg/mod/gioui.org@v0.8.0/gpu/gpu.go:359 +0x14d
gioui.org/gpu.NewWithDevice({0x7b9520, 0xc0004eec08})
	/home/chris/Code/go/pkg/mod/gioui.org@v0.8.0/gpu/gpu.go:349 +0xac
gioui.org/gpu.New({0x7b3208?, 0xc000072de0?})
	/home/chris/Code/go/pkg/mod/gioui.org@v0.8.0/gpu/gpu.go:337 +0x34
main.main()
	/tmp/foo/main.go:75 +0x346
exit status 2

They provided this reproducer code, which I have tested. It does indeed crash as written (on both v0.8.0 and main), but I can't see anything wrong with it. They report that the same code works if you instead use OpenGL ES, but I don't have the code modifications for that permutation.

My system that reproduces this:

 $ uname -a
Linux jetsam 6.13.4-arch1-1 SMP PREEMPT_DYNAMIC Sat, 22 Feb 2025 00:37:05 +0000 x86_64 GNU/Linux
$ sway --version
sway version 1.10.1
$ go version
go version go1.24.0 linux/amd64

glxinfo