Open alandefreitas opened 4 years ago
Maybe somebody could correct me if I am wrong but given that the OpenGL framework is a state machine you cannot split the rendering pipeline between threads, but you can transfer the entire process to another thread if need be.
I tried this a while ago when trying to do similar and it wouldn't work for this reason. HTH
calling glfwMakeContextCurrent(window)
when you use OpenGL in a different thread for the first time should help. And if you don't need the context anymore in a thread, call glfwMakeContextCurrent(nullptr);
to "unbind" the context. In one of my projects, I use something like this to wrap all my OpenGL calls to make them thread-safe:
void executeOpenGL(std::function<void()> const &functor) {
static std::recursive_mutex openGlMutex;
std::lock_guard<std::recursive_mutex> lg(openGlMutex);
glfwMakeContextCurrent(window);
functor();
glfwMakeContextCurrent(nullptr);
}
I was browsing the examples in this repository looking for something that could help me. I'm trying to create a plotting backend that would work like a matplotlib backend for C++. There would be an independent window for plots whose contents would be updated depending on what happens in the main thread. Such a backend doesn't make sense if it blocks the main thread. Is that possible with glfw, or openGL, or any other related library? If so, can I still use your material as a reference?
That's what I tried to do (on Mac OSX). I have an idea of why it doesn't work but I have no idea if there is any way to solve it. I've tried all kinds of variations on that code already.
The error:
If I move the initialization functions inside the thread, then the error becomes:
If I move the initialization functions to the main thread but create window in inside the thread (from
glfwCreateWindow
), the error is still: