I never tried but I think this is not a wise thing to do because while a window message is being processed , drawing to it might interfere or produce some undesired results. (Remember that you render frame thread will not be synchronized with the message pump thread).

There are good reasons for wanting to put your rendering code into a separate thread, but my guess is that this isn't one of them. Do you have any evidence (statistics/profiling data) from your application to suggest that handling large numbers of messages from Windows is causing a problematic slow-down?

If so, then yes, maybe it would be worth shifting rendering to a separate thread (or maybe not - depending on circumstances there may be some other alternative), but if you're just going by your guess of something that will cause a slow-down, then it would be better to wait till you have some hard evidence before worrying about it.

Besides:
1 - People probably won't be watching your application extremely closely while they're dragging the window (so a render slow-down probably won't be noticed).
2 - Dragging a window isn't something that happens all that often, and when it does happen it's usually over pretty quickly.
3 - Computers are really fast nowadays; you might be surprised at how well rendering continues even when your application does seem to be receiving lots of messages.

Having said all that, if you do decide to go multithreaded, be careful to check the documentation for all the functions you use. Some of them can only be called from the thread that owns the window anyway. Others are designed to be thread-safe if you pass D3DCREATE_MULTITHREADED to CreateDevice.

You will need to use synchronisation primitives like Mutexes for various things if you go multithreaded, but unfortunately it won't be quite as simple as wrapping all DX calls in mutex locks.

John B

You could also simply reorganize your message pump loop so that it always calls RenderFrame within some time frame regardless of how many messages are waiting in the queue, instead of pumping every message until the queue is empty and then calling RenderFrame. And for those cases when a string of messages is sent to the window message procedure rather than posted to the queue, you can still call RenderFrame from the message procedure at the desired minimum frequency.

[Edited by - Mastaba on March 16, 2007 8:37:07 PM]

Quote:Original post by DartraKraft
On a side note, Fraps gives really strange frame rate readings. Seems like most of the time it only does 85 fps. But if I drag a window over the top of mine, it jumps to 5000 or 6000 fps. What causes that?

This is because the rendering (or at least part of it) doesn't take place due to the render window being obscured. None of the rendering gets past the early stages of the graphics pipeline and therefore renders extremely fast resulting in an extremely high frame rate.

Degra