I use threads to async-load heavy 3D Models, with their own opengl context, created using an invisible window, as proposed in the GLFW doc. The temp windows are created and destructed in the main thread. It works well.
But, on windows (10), if the main window (main thread) is fullscreen, there is a black blink when a temp window is destructed. There is no such issue on Linux. I traced it down to the call to win32 DestroyWindow().
So my question is : do you expect to add (more or less soon) a function to create an opengl context without creating a window ?
Background loading of models on a seperate thread with OpenGL without using a seperate context is possible, mainly by loading the model and textures into memory and then creating the required OpenGL state on the context thread, as it’s usually the file loading and processing which takes the time.
You can also use persistent mapping, or map the buffer on the main thread and then copy the data on another thread.
That issue was rather about creating a gl context without creating a window, if I’m not wrong ?
I’m aware of the other ways to load 3D models using threads. I was just wondering if it is expected to add calls to ‘directly’ create shared gl context, based on an already opened window (so that you already have the window context, pixel format and so on, needed to create a gl context).
So if I understand it your actual question is “do you expect to add a function to create multiple OpenGL contexts for one window?”.
I don’t expect this to be added unless there is a large demand or someone is willing to undertake the work across all OS GLFW supports. This is relatively easy on windows but I don’t know about some of the other platforms.
Coming back to this it would seem to me that an easier solution for you would be to keep the invisible window open and re-use it when you need to load another model.
If you’re interested in working on a multiple contexts for one window then I would create an issue and/or start an implementation with your favourite platform as a proof of concept. There is a related issue:
Yes, one hidden window could be kept and reused. Or even a pool of hidden windows could be used to enable parallel loading of several models (can be useful in some cases). But that’s more or less a ‘trick’, right ?
So yes, multiple contexts for one window would be the preferable solution (imho)… If you agree to start writing a POC for Windows (by defining the API and possibly the datastuct to record the contexts), I’m definitely willing to help. We are coding for Windows/Mingw-w64 and Linux, but I could also potentially have a look at macos (I’ve got a MacMini).
I finally had the opportunity to test your patch.
It works like a charm, and was super easy to implement.
As you mentioned in the FR, glfwGetCurrentUserContext() is not needed (at least in my case), given that I create one user context per thread (used to async-load a 3D model) and so I keep a reference to the created user context in each thread.
Thanks a lot for your work !
Do you expect to include it in the next 3.3 release, anytime soon ? Or at least on your master branch ?
Excellent - I’ll start implementing the other OS variants when I get time.
First we need to implement this for other OS, write the documentation and release notes, then there will be a pull request followed by a review and merging. This can take some time, there are 46 open Pull Requests, some of them going back years - this is an open source community driven project so giving any timing is difficult.
This is a fairly simple branch to maintain, so my advice would be to fork GLFW, create your own branch and then merge my branch or just cherry pick the changes so you can keep control of your own version.
I presume you mean the GLFW master branch, in which case as above this takes time.
WGL and GLX are what we currently use.
We are currently working on a port to Vulkan, but it will take some months before it will be ready.
I had a look to glx_context,c, expecting to propose you a GLX implementation, but as far as I can see, it would need to keep track of the FBConfig chosen when the main window was created, and so probably a change of a current struct (store the FBConfig into window->context.glx ?). Such a ‘deep change’ is not something that I can do without an ack of the dev-leader…
I’ll take a look at GLX shortly - probably over the weekend.
Vulkan is quite different to OpenGL, and the window is created without a context then a Vulkan window surface is created which is used to present the render to the screen. There is no direct equivalent of the OpenGL context, and many functions are thread safe. Thus there isn’t a need (or even a potential) for this API to be ported to Vulkan.