ResizeBuffers Bug

Started by
6 comments, last by gfxCahd 10 years, 2 months ago

calling swapChain.ResizeBuffers doesn't have any effect on the refresh rate. I go through the trouble of getting a modeDescription that the monitor supports (GetClosestMachingMode) and yet the swapChain remains stuck at 60fps, and I get the warning

DXGI Warning: IDXGISwapChain::Present: Fullscreen presentation inefficiencies incurred due to application not using IDXGISwapChain::ResizeBuffers appropriately, specifying a DXGI_MODE_DESC not available in IDXGIOutput::GetDisplayModeList, or not using DXGI_SWAP_CHAIN_FLAG_ALLOW_MODE_SWITCH. DXGI_SWAP_CHAIN_DESC::BufferDesc = { 800, 600, { 60, 1 }, R8G8B8A8_UNORM, 0, 0 }; DXGI_SWAP_CHAIN_DESC::SampleDesc = { 1, 0 }; DXGI_SWAP_CHAIN_DESC::Flags = 0x2;

So, is this a confirmed bug?

Advertisement
Yep I remember this bug when I was playing wityh my DX engine. If I remember correctly, I ended up queiring new back buffer out of swap chain.

So, whenever I want to transition to fullscreen from windowed, or change fullscreen resolution I need to recreate the swapChain?

p.s. I thought DXGI was created to make window handling easier. This is turning out to be worse than the d3d9 way of doing things...

ResizeBuffers works but your general observation is correct: DXGI is simpler if you're using it at the most basic level (starting up in a single mode and never switching from that mode aside from using Alt-Enter to toggle fullscreen/windowed, letting DXGI handle the toggle) but as soon as you try to implement your own mode switching, with support for different resolutions, refresh rates and windowed versus fullscreen, it becomes significantly more complex than the old way.

As a general rule, the sequence that works looks like this:

If going from fullscreen to windowed, call SetFullscreenState (FALSE, NULL), then call ResizeTarget.

If going from windowed to fullscreen, call ResizeTarget, then call SetFullscreenState (TRUE, NULL).

Otherwise just call ResizeTarget.

Wait for a WM_SIZE message to come in (the OS will generate this automatically in response to the ResizeTarget call).

Call ClearState, OMSetRenderTargets (NULL), and release your current RenderTargets to ensure you've cleared any outstanding references on your buffers.

Call ResizeBuffers.

Recreate anything that needs to be recreated (typically your backbuffer's RTV, your depth/stencil texture and it's DSV, and any other render targets you're using)

Generally I don't respond immedately to events as they happen when doing this; I've found that doing so is almost 100% guaranteed to get things happening in the wrong sequence and mess up badly. Problems I've observed include back buffers not being sized correctly for the window, the taskbar size interfering with fullscreen modes, etc. Instead I just set a flag on my video state, and at the start of the next frame I check for this flag and respond to it there. If the response requires any kind of follow-up, I set another flag and defer again to the following frame. If all flags are clear, I draw the frame, otherwise I skip drawing it.

It's also important to use MakeWindowAssociation with DXGI_MWA_NO_WINDOW_CHANGES | DXGI_MWA_NO_ALT_ENTER, using a DXGI Factory obtained via SwapChain->GetParent, otherwise DXGI may kick in and decide to do it's own thing (instead of what you want it to do) at any point during this process.

Direct3D has need of instancing, but we do not. We have plenty of glVertexAttrib calls.

Have you gone through all of the details here to make sure you are following the requested process when jumping from windowed to fullscreen or vice versa? I just tried doing this with one of my samples, and I get the same behavior when Alt+Enter swapping between fullscreen and windowed, and it appears others have had similar issues (here too).

I would be curious to hear if anyone is able to do the mode switching without this performance warning...

Ok, it's been a while, but thank you all for the replies.

A quick update:

I tried recreating the swapChain on resizing to fullscreen. This does result in the swapChain getting a new (and accurate) refresh rate. But the DXGI warnings persist.

DXGI Warning: IDXGISwapChain::Present: Fullscreen presentation inefficiencies incurred due to application not using IDXGISwapChain::ResizeBuffers appropriately, specifying a DXGI_MODE_DESC not available in IDXGIOutput::GetDisplayModeList, or not using DXGI_SWAP_CHAIN_FLAG_ALLOW_MODE_SWITCH. DXGI_SWAP_CHAIN_DESC::BufferDesc = { 720, 576, { 60317, 1000 }, R8G8B8A8_UNORM, 1, 2 }; DXGI_SWAP_CHAIN_DESC::SampleDesc = { 1, 0 }; DXGI_SWAP_CHAIN_DESC::Flags = 0x2;

Unless anyone has any ideas, I'm gonna concede defeat and just ignore this warning.

I would be curious to hear if anyone is able to do the mode switching without this performance warning...

This works for me:

- create swapchain with DXGI_SWAP_CHAIN_FLAG_ALLOW_MODE_SWITCH

- call MakeWindowAssociation with DXGI_MWA_NO_WINDOW_CHANGES and DXGI_MWA_NO_ALT_ENTER (this means you have to handle window messages and styles explicitely)

... then when switching from windowed to fullscreen:

- call ResizeTarget with the fullscreen parameters

- call SetFullscreenState(TRUE, NULL)

- call ResizeTarget with the same parameters as before except a zeroed refresh rate (why? I have no idea, it's what MSDN tells me to do)

- call ResizeBuffers

... although to be fair I don't remember if it was one of the above steps that made the warning go away or if it was a result of fiddling with window message handling.

^Thanks. I found something else that works

Calling resizeBuffers TWICE (once right before setting the swapchain to fullscreen, and once right after) removes the error for me.

I guess the confusion is caused by the fact that some people have resizeBuffers called when they get a WM_SIZE windows message, so they only call resizeBuffers once in their main function.

Also, create your swapChain with a refreshRate of Zero!

Btw, is there a way to test whether my game is flipping or blipping? I don't trust the D3D debug messages. The swapChain's refreshrate NEVER CHANGES after creation, and though a refresh rate of zero should in theory result in DXGI picking the appropriate refresh rate itself the second time you call resizeBuffers, I'd like to be able to verify this.

This topic is closed to new replies.

Advertisement