DirectX performance issues, multithreaded
Hi,I'm writing a DirectX application with two threads:
Main thread:- Processed Windows messages, renders frames
Secondary thread:When my main thread runs without Sleep(milliseconds), I get about 700 - 800 frames per second, but my engine thread does maybe 5 loops per second.
When I put Sleep(0) or any other small number into my render thread, the FPS drops to 64 (strange number btw). I am pretty sure I count my FPS correctly (QueryPerformanceTimer & count frames, after one second fps = framesRendered / timeElapsed).
My engine thread doesn't do much most of the time and it has Sleep(50) in it.For some reason it doesn't make a difference what sleep time I put into engine thread, I still get about 64 FPS in the main thread.Would anyone know why I suffer such huge performance hit?I would much appreciate any ideas.Thank you.-nagual
[2608 byte] By [
nagual20] at [2007-12-24]
From the documentation for the Sleep function:
<<You have to be careful when using Sleep and code that directly or indirectly creates windows. If a thread creates any windows, it must process messages. Message broadcasts are sent to all windows in the system. If you have a thread that uses Sleep with infinite delay, the system will deadlock. Two examples of code that indirectly creates windows are DDE and COM CoInitialize. Therefore, if you have a thread that creates windows, use MsgWaitForMultipleObjects or MsgWaitForMultipleObjectsEx, rather than Sleep.>>
Thanks for the answer.
I looked up the reference for MsgWaitForMultipleObjects and it appears to be used to synchronize multiple window threads. So it would be useful to me if my "engine" thread processed any window messages, which it doesn't.
MsgWaitForMultipleObjects sleeps until message of dwWakeMask are available.
My seems to be that the main thread sleeps for a minimum amount of time that's way more than the number of milliseconds specified.
Well, what you're specifying with Sleep() is the minimum number of milliseconds before execution of the thread can continue. There's no guarantee that it will happen immediately after that period has elapsed. Whatever time remains in your thread's time slice will be given to other threads with the same priority -- which could be longer than the 50 milliseconds you're expecting.
