Multi-threading does not work (Qt 5.13.1, OSG 3.6.4, MSVC 2019 x64, Win10) about osgqt

[mathieu]

Hi, Qt's openGL implementation needs to render from main thread. OSG's multithread starts multi-threading from the main thread into render Threads. These are not reconcilable...

[villains]

Hmm. That sucks. So there is absolutely no way to get multi-threaded OSG rendering with Qt?

[villains]

Is there a way to get the other operations (update and cull) to happen in other threads, keeping only the OpenGL drawing in the main thread?

[mathieu]

Sorry, but without refactoring osg there is no way it can be done. And refactoring osg is what got osgQt kicked out from main osg repo.

[villains]

Ok. That's unfortunate, indeed.

I appreciate your time!

[mathieu]

no problem, I needed this feature also but Qt's modern OpenGL handling makes this impossible without some refactoring either in Qt or in OSG...

[sdh4]

Correct me if I'm wrong but the needed refactoring under discussion is related to the Viewer class, parallelization of a render process, and the need to configure the automatically-generated threads with suitable contexts for rendering in the QT environment?

It looks like in certain applications a partially threaded render might be possible: Render to texture framebuffer(s) in a separate thread using a separate QT-created context and QT's makeCurrent() and doneCurrent() methods to do the context swaps.

Then the main QT thread can blit/compose/3D render from the texture framebuffers into the actual window. Does this sound plausible? It would at least prevent slow rendering from bogging down the main GUI thread.

The biggest potential pitfall I can think of would be the texture framebuffers not being available (because they are being redrawn) at an instant where the main QT thread wants a redraw. But I would imagine that just ignoring the paintGL() in that circumstance would recompose based on the prior output.

Make sense? Seem plausible?