Failed to make context current for threaded rendering loop

support
1

For a little while I’ve been working on an application that has the OpenGL rendering logic on a separate thread. This gives me a couple of options. One it let’s me render to the window while resizing/moving; It let’s me handle events while rendering is also happening at the “same” time. etc.

On MacOS (Apple Silicon) I’ve been dealing with the issue of it crashing. I found out it’s because while resizing or moving a GLFW window, MacOS is also using the Cocoa context for handling that. After a lot of trial and error, I found a solution online in where I can get the actual Cocoa handle (context) and place a lock on it while I’m running any OpenGL code (rendering). This completely fixed my issue.

However, I’m now dealing with Windows (11) where a similar issue seems to happen. I’m getting the following errors while resizing a window while the rendering is happening at the same time:

GLFWError: (65544) b’WGL: Failed to make context current: The requested resource is in use. ’

I’ve beel looking online but it seems there’s no similar locking (mutix) aproach on Windows, for the WGL context. Is there anything I can do to still fix the issue? I’ve added a while loop right after the MakeContextCurrent call, to check wether the GetCurrentContext actually returns the window context. And while that is false, it will keep trying to make it current. This works, but I’m still getting the warnings in the terminal.

It also does not seem like an actual fix, maybe someone can point me in the right direction? I’m not sure but I believe I’ve done this before on Windows, where rendering from a different thread just worked. One more detail I’ll give, I’m only making the context current in the rendering thread. It’s only ever current on the main thread when I initialize/create the window (context), after that it’s only the rendering thread and Windows system itself (apparently).

2

what you are running into is more of a context ownership issue and less of a **WGL** locking issue. A rendering context can only be current on one thread at a time . Windows might also do some operations on a window and briefly interact with the rendering context .

Repeatedly re-trying `wglMakeCurrent` will typically just spam the warning and not resolve the underlying contention. I’d make sure the main thread explicitly releases the context (`wglMakeCurrent(nullptr, nullptr)` or the equivalent in GLFW) before the render thread ever takes it and don’t make it current anywhere else after that.

Another option is to stop rendering while processing the resize, or to render into an offscreen framebuffer and present once the context is available again if resizing is still causing conflicts. That’s usually more reliable than trying to synchronise access with a mutex around the **WGL** context itself.

3

Thank you for your response. I’m not having the context current on the main thread at all. It’s Windows “forcing” it when a resize is happening.

You’re suggesting I render into a framebuffer, but that also needs the context?