1
Vote

MFC sample problem

description

The MFC sample project is sucking way too much CPU power, over 40% on my machine. I suspect that the drawing call resulted in the window to be invalidated and force the window to redraw itself repeatedly (kinda like an infinite loop).
Since Visual Studio 2013 community edition is free, MFC is available to everybody now. And as a mature GUI package, it might be a valid option for projects that require more user friendly UI.

comments

jzink wrote Dec 20, 2014 at 3:28 PM

Thanks for the report. You are right about the invalidation loop, which is intended to push the rendering as fast as possible. To be perfectly honest, I'm not an MFC expert, and this was just the first solution that I found to make the rendering update continuously.

Do you have a suggestion about how to improve the rendering loop? Is there a standard way to produce say 60 FPS updates on each of the rendered windows? If you can help out here, it would be greatly appreciated!

wxz wrote Dec 22, 2014 at 3:34 PM

My previous suspicion was wrong. After profiling the executable, it turned out that it was RendererDX11::Present() causing the high percentage of CPU usage. Specifically, on Ln 471:HRESULT hr = pSwapChain->m_pSwapChain->Present( 0, 0 );

The sync interval is set to zero so that the view is updated as fast as possible. It causes ClearRenderTargetView() and ClearDepthStencilView() (both in class PipelineManagerDX11) to be called a lot, which in turn drive up the CUP consumption.

It's not a bug as the code is doing what it's suppose to, but is it possible to allow the user to set the sync interval for Present() ? After I set the sync interval to 1, the refresh rate locks to the screen refresh rate (60Hz for my monitor) and CPU usage is dramatically lower.

jzink wrote Dec 23, 2014 at 1:23 PM

That makes sense, and it follows the general pattern that most of the other samples follow - to render as fast as possible. However, I fully see the utility in what you are describing. Since this is a basic template for an editor, it would make sense to find a better metric for rendering the views.

If you take a look at how the ImageProcessor sample runs, it uses such a custom system (although it is Win32 and not MFC) to only render and present a frame based on user input or several other events.

I could easily add some optional parameters to the RendererDX11::Present method that allow for selecting the presentation mode and the sync interval. To maintain backwards compatibility, I can just provide default values of 0, 0 to replicate the current functionality. That would allow customization for each swap chain, and would trivially allow me to update the MFC sample as you described above.

jzink wrote Jan 2, 2015 at 8:53 PM

This should be updated in the most recent commit. If you like it, I will close out this issue.