reduz wrote on Thursday, November 06, 2008:
I want to use one thread to handle input devices, and another thread for just rendering opengl commands, so i’m looking at how to do something similar to glxMakeCurrent, wglMakeCurrent, etc.
Please, no “why do you want to do this? do everything on a single thread, it’s better” answers.
dalfy wrote on Friday, November 07, 2008:
Hello,
In the context of a single OpenGL window application. It makes little or no sens to provide a mechanism to switch from one OpenGL context to another. Thus this functionality is not exposes by GLFW. The best solution consists in making all call to the OpenGL pipeline in the same thread that created the window. That should make sure that all command goes to the appropriate context. The input can then be processed in another thread. However, GLFW is not thread safe. So you should not make assumption on what is going to happen if you change the state of the glfw library from two different context without any synchronization mechanism. I would find more safer the following approach:
Do all the interaction with the OpenGL library in one thread and send input events to the event thread through whatever mechanism. That way you still have one thread for processing event and one for doing the rendering. It is just that the events are obtained in one thread and processed in another.
I hope it helps.
reduz wrote on Monday, November 10, 2008:
That makes your life more difficult, because if you are properly implementing a multi threaded 3D app/game, you expect your 3D thread to wait (sleep) on a command queue and wake when receiving events from the logic thread (like, move this object there, instance that object there, draw a frame, etc).
But you are also suggesting to handle input events in that thread, so then you can’t sleep waiting for graphical events/frames, thus making proper deferring 3D to a thread pretty much unimplementable task.
So, yes, this is not about multiple windows, i need a glxMakeCurrent/wglMakeCurrent, etc properly abstracted in GLFW so i can process input events in a thread, and graphic events in another.
dalfy wrote on Monday, November 10, 2008:
I do understand your needs I just say that you probably don’t need a make current if you do all the interaction with OpenGL in one thread and process the event in any other. The only thing you have to do carefully is the access to the glfw internal state which is not thread safe except if you add an exclusion mechanism around access to the library. I don’t think you need makeCurrent as long as you do the opening of the window and all the drawing operation in the same thread.
mekanikles wrote on Sunday, January 11, 2009:
I have the exact same request but maybe I’m missing the proper solution to this. The reason I want to context-switch GL is that the glfwPollEvents function seems like it needs to be run from the main thread. So does glfwSwapBuffers. (I know that glfwPollEvents can be run automatically on glfwSwapBuffers but I do not want that.)
It seems like the "neatest" thing is to have the render thread doing glfwSwapBuffers and the input thread do glfwPollEvents (since I assume that running glfwGetKey or something while another thread runs glfwPollEvents is bad).
Thus, I made a fix for it (I’ve not distributed this in any way, just a test). I added the functions “glfwReleaseGLContext” and “glfwLockGLContext”. These do what you might expect so the main thread can call glfwReleaseGLContext before starting the render thread which calls glfwLockGLContext on startup. This allows the render thread to call glfwSwapBuffers while the input thread (main thread) can poll events and such and it works nicely.
The fix also modies the callback functions so that you send a ‘void* data’ with them as well. This to allow class methods to be used as callbacks.
I’d love to contribute to the project but are these fixes of any interest to anyone or should I just keep them to myself? 
mekanikles wrote on Sunday, January 11, 2009:
I have the exact same request but maybe I’m missing the proper solution to this. The reason I want to context-switch GL is that the glfwPollEvents function seems like it needs to be run from the main thread. So does glfwSwapBuffers. (I know that glfwPollEvents can be run automatically on glfwSwapBuffers but I do not want that.)
It seems like the "neatest" thing is to have the render thread doing glfwSwapBuffers and the input thread do glfwPollEvents (since I assume that running glfwGetKey or something while another thread runs glfwPollEvents is bad).
Thus, I made a fix for it (I’ve not distributed this in any way, just a test). I added the functions “glfwReleaseGLContext” and “glfwLockGLContext”. These do what you might expect so the main thread can call glfwReleaseGLContext before starting the render thread which calls glfwLockGLContext on startup. This allows the render thread to call glfwSwapBuffers while the input thread (main thread) can poll events and such and it works nicely.
The fix also modies the callback functions so that you send a ‘void* data’ with them as well. This to allow class methods to be used as callbacks.
I’d love to contribute to the project but are these fixes of any interest to anyone or should I just keep them to myself?