do I need to render on a second thread?

Hi,

I’m seeking advice in whether or not I should perform my rendering operations in a second thread. I hope that someone on this forum can help me out.

Brief description:
MFC SDI data acqisition application.
Hardware is an optical strain measurement device.
Measurements are performed on a dedicated acquisition thread.
Main thread is notified of new data, buffered data is copied from acquisition thread to object in main thread.
PostMessage used on main thread to signal a redraw.

On the whole this functions well, it’s a sound architecture but I do get varying performance on different plaforms due to the rendering capabilities. The rendering itself is very simple, I use a mixture of display lists and immediate mode. Some of the furniture in the view does not change, but the trace lines representing the data are always changing so I render those in immediate mode.

Currently I have to make an allowance on the acquisition thread for the main thread to catch up with the rendering at the highest acquisition speeds. This allowance (a delay in milliseconds) is small for my development system as it has good hardware acceleration (even though it is an integrated ATI monstrosity!), but in deploying on some lowend systems I have trouble where the interface become unresponsive.

Hence, I think that I need to go to another level and now move all of that cpu load off of the main thread, and this is where I need help. I’ve struggled to find an online example of this being done. I have my own thread class that I am happy to use but I don’t know of an efficient way to signal the rendering thread during acquisition. Can anyone help with this?

My colleague wants me to drop GL and render in GDI instead. Not only due to shear bloddy-mindedness do I not want to do it, but I do believe that there’s no technical reason why GDI should prove to be faster than GL.

Many thanks if you read this far.

matthew

Ok, to put it simply, you’re having trouble finding out how to render in a different thread because OpenGL (itself) must be run in only one thread. This shouldn’t be a problem, as long as you keep all of the OpenGL code restrained to that one thread. Whether you should or should not run your program as a multithreaded app, well, that’s up to you. Just keep OpenGL code (all of it, init, render, … all of it) in one thread.

Currently I have to make an allowance on the acquisition thread for the main thread to catch up with the rendering at the highest acquisition speeds. This allowance (a delay in milliseconds) is small for my development system as it has good hardware acceleration (even though it is an integrated ATI monstrosity!), but in deploying on some lowend systems I have trouble where the interface become unresponsive.
It depends how you have setup your rendering. You have a MFC SDI project, but how are you rendering and processing GUI commands?

It’s possible to have rendering and GUI in the same thread.
You need an infinite loop. Catch and process WM commands first, if there is non, then you render.
The effect will be that if user clicks on a menu, then rendering gets halted automatically.

I don’t think you should render inside a different thread. Reason is that you only import data from another thread, not gl stuff. You don’t create any gl stuff neither.

So, just render inside the main thread.

Hope this helps.