What would cause my graphics to stop updating when the mouse is moving?

Question

I'm learning metro development with c++, DirectX, win8 CP, vs11 beta. I've come across some unexpected behavior:

Running the tutorial series ( Direct3D Tutorial Sample 1 ), and any sample or app for that matter, If I'm watching motion on the screen such as the cube slowly rotating, and I move the mouse, the object stops updating/rotating until I stop moving the mouse.

Here is a very short video of what I mean: http://www.screencast.com/t/cEHkVUaRcw

It even does this with the shooting sample game, which is very mouse intensive. It makes all the motion very jumpy.

I believe it has something to do with the system. I can interrupt the dispatcher from processing messages and it stops manifesting this behavior so it feels like the computer is so busy processing messages that it can't keep up with the rest of the updating. But this problem only started recently so I do not believe it is a problem with my computer's processing power.

Has anyone else experienced this and know how to resolve it or does anybody have an idea into why this is going on?

Here is the game loop code that MS ships with the sample.

while (!m_windowClosed)
{
    timer->Update();
    CoreWindow::GetForCurrentThread()->Dispatcher->ProcessEvents(CoreProcessEventsOption::ProcessAllIfPresent);
    m_renderer->Update(timer->Total, timer->Delta);
    m_renderer->Render();
    m_renderer->Present(); // This call is synchronized to the display frame rate.
}

Thank you.

Answer 1

I finally found the reason for this behavior. I have a password manager app that loads at startup and is designed to automatically input username/password for my various websites.

When, in a metro app (or at least the DirectX ones), if the window core dispatcher is flagged to ProcessAllIfPresent, it spends time each frame loading and unloading one of the dlls associated with the password manager program.

Once I went to the task manager startup tab and disabled that password management app and closed it down, the behavior went away. Starting it back up brings the behavior right back.

I found it by monitoring the output window while running my DirectX app. I didn't notice it until I discovered "Simulator Debugger" mode where the output window was visible while running the app.

Answer 2

My guess would be the window's callback function, or that ProcessEvents function, has some code for handling mouse movement. When this callback gets messages, your "user" code will be halted while the message is being processed. Mouse movement could be a huge number of messages, hence completely stopping your application from updating.

I personally haven't seen this with simple mouse movement, but sooner or later (dragging the window around, for example) you would likely have encountered this. Edit: well, in a metro style app you might not be doing too much dragging of windows.

If you run your update/render loop in a separate thread from the message processing, it will be unaffected by the callback processing messages. You will need some form of synchronization though if you want to call device or devicecontext methods in reaction to some messages, as D3D doesn't take kindly to being called from multiple threads at once. (resizing your frame buffer after receiving a WM_SIZE message indicating the window has been moved or resized, for example)

Answer 3

Message processing should be very quick. What you need is a profiler to find out why it isn't.

Profile both the stationary mouse case and the rapidly moving mouse case and compare the two profiles to find out what's taking so long.

Answer 4

I saw this happen with another game project. The mouse messages were being immediately dispatched into a crappy UI library (libRocket). High- resolution gaming mice could generate hundreds of mouse events per frame, and the UI processing simply couldn't keep up.

The solution was to simply set a flag that the mouse had moved and then -- after the event loop -- signal to the UI library that the mouse moved and polling the OS for the current mouse position.

The gaming mice can be pretty ridiculous since they are geared for specs that make no technical sense, but many "l337 gamers" really have no idea how games or computers work and spend tons of money buying low-latency hardware that no game can even take advantage of. (even if you turn off vsync, for instance, the physics that drives all game logic is often fixed time step with only interpolation for high-fps graphics playback.)