Complete GLFW v3.4 integration and fix TODOs (supersedes #400) - #414

Some more items:

• Added GLFW 3.4 platform API wrappers: GetPlatform, PlatformSupported, and Platform enum values.
• Added custom allocator support: Allocator + InitAllocator.
• Added Vulkan loader/presentation wrappers: InitVulkanLoader and GetPhysicalDevicePresentationSupport.
• Added direct error query API: GetError and NoError.
• Added missing GLFW 3.4 error mappings: CursorUnavailable, PlatformUnavailable (and handling in Init / standard cursor creation).
• Added missing window/input API pieces: Window.GetTitle, CursorCaptured, ContextNoError, AnyPosition, plus new 3.4 hints and hint values (ANGLE, Wayland, Win32, X11 Vulkan surface, etc.).
• Updated README to be in sync with v3.4 usage and changelog (including note that GLFW_UNLIMITED_MOUSE_BUTTONS is not in the vendored GLFW revision).

Brought this PR up to date with the latest go-gl commits. Everything should be in place now.

I tested this on my wayland system (KDE, debian 13.4) with opengl ES 3.2. It seems to work fine, but I noticed the window doesn't actually render until the first SwapBuffers call. With x11, it just shows a black window, but in wayland there's no actual window, just the app's icon in the taskbar. Not a huge issue, since I can just add a SwapBuffers call right after I make the window.

Also, I see the window isn't the size I asked for, but about 30% bigger in each dimension. Is this some hidpi thing? I am on a 4k 32" monitor

Hello @hackbar
Thanks for testing this :)

What you describe matches typical Wayland behavior: unlike X11, a compositor may not show the toplevel until the client has attached and committed a real buffer, so seeing only the app icon until the first SwapBuffers is not surprising.

This is also reflected in the vendored GLFW 3.4 Wayland code. In v3.4/glfw/glfw/src/egl_context.c:283, there is even a note:

// NOTE: Swapping buffers on a hidden window on Wayland makes it visible

The size difference is most likely HiDPI / compositor scaling. In GLFW 3.4, window size and framebuffer size are separate: the window size is in screen coordinates, while the framebuffer size can be scaled for HiDPI.

Could you check what GLFW reports on your setup?

w, h := window.GetSize()
fbw, fbh := window.GetFramebufferSize()
xscale, yscale := window.GetContentScale()
fmt.Printf("window=%dx%d framebuffer=%dx%d scale=%.2fx%.2f\n", w, h, fbw, fbh, xscale, yscale)

If GetSize() matches the requested size, but GetFramebufferSize() is larger and GetContentScale() is above 1.0, then this is most likely HiDPI / compositor scaling on Wayland. If GetSize() itself is larger than requested, that would point to an actual sizing issue.

Thanks,
Alex

Hmm, it looks my GetSize and GetFramebuffer size match what I requested, and ContentScale is 1 in both dimensions.

This doesn't seem to match the window size I'm getting, which is 1.25 times larger. This does match the scale I set in kde's settings. Setting that to 100% does give me the same windows size as I requested.

So it seems like wayland is doing some kind of scaling for me automatically? Is this a thing, or is there any way to change the setting?

Could you check one more thing on top of the previous printout: what does glfw.GetPlatform() report after Init()?
It would also help to print the same values once more after the window is actually mapped, i.e. after one initial SwapBuffers() + PollEvents().

If native Wayland still reports window == framebuffer and scale == 1.0 even after the first frame, while KDE at 125% still makes the window appear larger, then this points to upstream GLFW / compositor scaling behavior rather than go-gl itself.

GetPlatforms return 0x60003.

Even after the first buffer swap it's showing the framebuffer and window are the same size (what I requested) and the scale is 1.0.

I'll try to see how KDE scaling works. I'd imagine the kwin compositor does things the standard wayland way, but maybe it's doing something weird.

Could you check whether the compositor is advertising the needed protocols?
wayland-info | grep -E 'wp_fractional_scale_manager_v1|wp_viewporter'
and one step deeper
WAYLAND_DEBUG=1 ./app 2>&1 | grep -E 'wp_fractional_scale|preferred_scale|wp_viewporter'

A good next check is whether KWin is actually sending the fractional-scale callback for the window (the second grep I sent). GLFW should request it, but GetContentScale() will stay at 1.0 unless the compositor replies with preferred_scale. If you run the test with WAYLAND_DEBUG=1, we can check whether GLFW sends get_fractional_scale and whether KWin sends preferred_scale back.

Which tests? just printing out the window/framebuffer/scaling sizes?

here's the logs for printing the sizes etc: https://pastebin.com/zP2gYkZt

Is there anything else I can do to help test this? Other than than the scaling, which I don't really mind once I figured out what was happening (my app is primarily fullscreen), it's working well for me.

I have been meaning to review this but I'm afraid that I have very little time for open source at the moment due to writing my Master's thesis.

FWIW, I have been using this PR in https://cogentcore.org apps for a week or so without any issues on my macbook. Given how difficult it is to actually use the PR code from another package (because 3.4 doesn't exist in any package that go modules know about), I haven't tested on other platforms. And also given that using this requires changing the import paths, perhaps it makes sense at this point to fast-track the approval, and then plan to address any issues that come up later?

Agree. Since this requires explicit import changes, it won’t break existing integrations by default. We can address edge cases as they arise.

Yeah, I think that makes a lot of sense.

Perhaps @dmitshur has more time to look at it?

This is still working great - thanks!

I'll file a bug to track the KDE scaling issue. I meant to do that, but forgot.