Hi. I’m fairly new to opengl coding and am trying to make physics simulation in Linux starting from examples I found in an opengl tutorial.
For performance reasons, there will be many threads that update the “world”, entirerly on the CPU side using no opengl-calls, so I suppose they will not be a problem.
But then my plan is to have 2 more threads:
One will call glfwPollEvents(), and respond to the keyboard.
The other one will do all the drawing.
Both threads/loops are written and work fine, but alas only one at a time, i.e. the one that has the “current” context.
I don’t want to do keyboard reading and drawing in the same thread because the drawing can get stuck for a long time because of temporary bugs or having to wait for the world-update to finish.
The program should be able to react to keyboard input even when the drawing is “stuck”.
I also don’t want to bounce the “current” context back and forth between the two threads by calling glfwMakeContextCurrent(nullptr) in one and glfwMakeContextCurrent(mywindow) in the other, as a “stuck” drawing thread cannot be trusted to yield the context fast enough.
Is there some form of sharing that can make the drawing and keyboard-reading thread run independently?
First, why does the input thread need an OpenGL context?
In GLFW, you can’t create a context separate from a window. You can create a hidden window with its own context, and that context can share data (buffers, textures, programs) with another context. Whether that’s of any use depends upon why you want the input thread (which has to be the main thread) to have access to a context.
I thought the input thread needed a context because when I pressed a key after having transferred the context over to the drawing thread, the program crashed. I guessed that was because the input thread no longer had a context. However, more testing now revealed that it in fact did read the keys, and crashed because of something else. Thank you.