So if I'm understanding correctly
To my understanding yes.
would the following approach be valid?
I'm afraid it's not that simple. Unfortunately OpenGL is for better or worse single threaded. An OpenGL context can be made current in only one thread at a time. If you want to render in multiple threads you have two choices:
Have one context, synchronize the threads and switch the context to be current in only one of them at any given time. In practice this is useless as you are rendering in only one thread while the others wait for their turn, thus the whole effort of threading is wasted because the rendering is serialized anyway.
Create multiple OpenGL contexts and make them share resources. This way you can make multiple threads, each with its own context, render at the same time. Each background thread would use a QOffscreenSurface and the main thread would use a window.
An FBO does not belong to a surface. It belongs to an OpenGL context. You can share resources like textures or buffers, but FBOs can't be shared between contexts.
Having said the above, one approach would be to create worker threads, each with its own OpenGL context made current on a QOffscreenSurface, rendering to a texture through an FBO. These textures would be then used to render them to an FBO in the main thread. Some synchronization will be needed to assure the textures updates are visible in other threads before using them for rendering.
Note however that, as I said earlier, concept of threads has been and, to some degree, still is alien to OpenGL. The above scenario will most probably be penalized, as most OpenGL drivers serialize the calls anyway and jump enormous hoops to give you the impression of multi-threading, with varying results. In many cases single threaded rendering turns out to be faster, mostly due to no need for synchronization. That is however something you will have to heavily profile for your case.
