[osg-users] Running a per-frame task on the graphics thread

[James Turner]

Hello,

Related to my other post about integrations with QtQuick, to achieve optimal performance I need to run a task on the graphics thread with some very particular timings, and I’m hoping for some advice on the most compatible way to achieve that. Especially, I’d like a solution which is compatible with all, or most, of the OSG threading modes.

To explain, QtQuick can be rendered in ‘foreign’ rendering contexts and threads (such as OSG’s graphics thread). There is a basic render function which does the bulk of the drawing, and this does no cross-thread communication; hence it’s well suited to be run in a Drawable’s drawImplementation or an osg::Camera post-draw callback. And I expect that my QtQuick content will be rendered as a HUD or overlay so I expect this part to happen almost at the end of the graphics thread’s frame, right before the swap.

However, there is a pre-phase (the sync phase), which needs to be run with the main thread blocked, which synchronises data, but may also make OpenGL calls : for example creating textures or buffers, or uploading shaders. Often it does nothing (if the QtQuick scene didn’t change that frame). What I’d like is for the graphics thread (assuming it exists) to run this task as early as possible in the frame, and definitely before osgViewer::frame returns; I guess this is conceptually the same as waiting on the dynamic objects guard which also blocks frame() from returning control to the main thread.

I’ve read the implementation details of osgViewer::frame (and ViewerBase) of course, but I’m still not certain what is really the nicest way to achieve what I need, while keeping the maximum possible amount of overlap between the main thread and graphics thread. (Fortunately I don’t think the cull threads are affected at all by this integration)

Any suggestions appreciated!

Kind regards,
James