Basic concept of message loop in directx - directx

Question

Well I find weird point of message loop.
first, lock this code below
MSG msg = {0};
while( WM_QUIT != msg.message )
{
if( PeekMessage( &msg, NULL, 0, 0, PM_REMOVE ) )
{
TranslateMessage( &msg );
DispatchMessage( &msg );
}
else
{
Render(); // Do some rendering
}
}
It is a tutorial of directx and this part is part of message loop.
If I click a mouse, It goes to queue as Message.
So Input like this should be process in proc function of win api.
Now that peekMessage return true, render() will not be called in frame when I clicked.
I think code be changed if~else to if~if for render when I click.
Can you explain this??

Answer 1

Your understanding is close, but not quite right. The loop isn't run once per frame. Rather, what happens is that for every iteration of the loop, either a single message is processed or Render is called. Effectively this makes rendering the lowest priority, but keeps your application responsive. The loop may be run many times or few times for each frame drawn, depending on how much work there is to do.
Does Render directly call Present? Or does it invalidate the window? If it invalidates the window, you would not want to change to always calling Render like you mentioned, because you'd risk not redrawing the window between renders.

Answer 2

Essentially this loop will process any pending Win32 messages for your window, and if there aren't any, it will render a frame. If it sees a WM_QUIT message, it exits the loop to quit the app.
There's no need for a 'throttle' because DirectX Present will block the thread (i.e. suspend it) if there are already 3 frames pending to render.
This model assumes you are doing one frame 'Update' per 'Render' call which isn't that realistic for a game, but it is simple for the tutorial. Extending the tutorial loop with StepTimer would look something like:
#include “StepTimer.h
DX::StepTimer g_timer;
...
MSG msg = {0};
while( WM_QUIT != msg.message )
{
if( PeekMessage( &msg, NULL, 0, 0, PM_REMOVE ) )
{
TranslateMessage( &msg );
DispatchMessage( &msg );
}
else
{
g_timer.Tick([&]()
{
Update(g_timer); // Update world/game state
});
Render(); // Do some rendering
}
}
...
void Render();
void Update(DX::StepTimer& timer);
StepTimer defaults to using variable step updates which means Update is called once per frame with whatever time delta and then Render is called once.
You can use a fixed-step update (say 60 times a second) like this:
g_timer.SetFixedTimeStep(true);
g_timer.SetTargetElapsedSeconds(1.f / 60.f);
In this mode, you'll have all pending Win32 messages processed, and then Update is called as any times as needed to keep up an average of 60 fixed-step updates per second, and then Render is called once.

Answer 3

The Render() inside the else basically gives preference to handling messages in the queue over rendering. Moving the mouse over the directx rendered window will add messages quickly to the message queue, but not fast enough to cause rendering to be delayed to any degree you'd ever see it. There is no advantage to rendering with each iteration because the iterations happen much faster than each frame is generated in your swapchain and much faster than a new message could swamp your queue. Most computers today will run this loop more than once per millisecond and even mouseover events happen less often than this. You wouldn't be wrong to render with every iteration, it's just unnecessary. With the example running, moving your mouse over the directx window as quickly as you can will cause fewer than 10% of the iterations of this loop to handle a message and delay rendering.
This message loop is executed as quickly as possible and has no facility to detect when the swapchain is ready to render. The PeekMessage checks to see if there's a message in the queue. If there is, it processes it, if not it Renders. What you're worried about is that a sequence of window events will cause the render to be delayed, but that's practically impossible. No matter how fast messages are sent to the queue, the swapchain is rendered more than 10 times faster than it needs to even for 60fps. This loop is the cause of high CPU utilization. The reason for it may be to simplify the tutorial, but as it's an inherently complicated environment. You might modify the swap chain in a separate thread if you're worried about the message queue delaying frame rendering.
To improve the CPU efficiency of the example program, just add a Sleep(8); at the bottom of the Render() routine. This will cause the message handler/render thread to pause between cycles handling messages and rendering at about 120 times per second. You can improve upon this by using high resolution timers and a modulus based sleep between cycles.
A good source of information to improve this example can be found here.