DirectX Graphics Infrastructure (DXGI) Full Screen Settings problems, infrastructuredxgi

DirectX Graphics Infrastructure (DXGI) Full Screen Settings problems, infrastructuredxgi

Https://msdn.microsoft.com/en-us/library/windows/desktop/ee417025 (v = vs.85). aspx

Not complete...

 

DXGI was introduced in Windows Vista and encapsulates the underlying work required for Direct3D10, 10.1, 11, and 11.1. From the perspective of a Direct3D 9 graphics programmer, DXGI encapsulates most enumeration, the creation of switching chains, and other Code previously encapsulated in Direct3D 9 APIs. When porting an application to DXGI, Direct3D10. X, and Direct3D 11. X, you need to consider some precautions to ensure that the program can run smoothly.

 

Full Screen questions:

From Direct3D 9 to DXGI and Direct3D 10. x or Direct3D 11. when switching from window mode to full screen mode, the problem may usually lead to a headache for developers, the main problem is that Direct3D 9 applications do not need to be closer to window styles and window states than DXGI applications. When the code in the switch mode is run in DXGI, some unexpected results are often caused.

Usually, the Direct3D 9 Application forces the device to enter full-screen exclusive mode by setting the front-end cache resolution, and then sets the background cache resolution to match. A separate way is used to change the size of the form, because the program has to be managed by window process and will receive a WM_SIZE message at any time.

 

DXGI tries to simplify the operation by merging the two parts. For example, when the border of the form is dragged in window mode, the application receives a WM_SIZE message to process the message. DXGI captures the message and automatically changes the front-end cache size. The application only needs to use the size parameter passed by WM_SIZE and callIDXGISwapChain: ResizeBuffersResets the backend buffer size. Similarly, when the form is switched between full screen and window mode, the application can simply callIDXGISwapChain: SetFullscreenState. DXGI resets the front-end buffer size to match the full-screen mode operation, and sends a WM_SIZE message to the application. The application callsResizeBuffersFunction,Just like dragging the border of the previous form.

SharpDX code example:

// Void renderForm_KeyDown (object sender, KeyEventArgs e) {if (SwapChain. isFullScreen) {if (e. keyCode = Keys. escape) {SwapChain. isFullScreen = false ;}} else {if (e. modifiers = Keys. alt & e. keyCode = Keys. enter) {SwapChain. isFullScreen = true ;}}// WM_SIZE event void renderForm_ClientSizeChanged (object sender, EventArgs e) {if (renderForm. clientSize. width! = 0 & renderForm. ClientSize. Height! = 0) // The minimum size is 0 {backBufferWidth = renderForm. clientSize. width; backBufferHeight = renderForm. clientSize. height; Disposer. removeAndDispose (ref backBufferTexture); Disposer. removeAndDispose (ref backBufferTargetView); // SwapChain. resizeBuffers (1, backBufferWidth, backBufferHeight, Format. r8G8B8A8_UNorm, SwapChainFlags. none); backBufferTexture = Texture2D. fromSwapChain <Texture2D> (SwapChain, 0); backBufferTargetView = new RenderTargetView (device, backBufferTexture); device. immediateContext. rasterizer. setViewport (new ViewportF (0, 0, backBufferWidth, backBufferHeight, 0.0f, 1.0f ));}
}

 

 

 

The methods discussed earlier follow a very special method. DXGI uses the default desktop resolution as the full screen mode. However, many applications switch a preset resolution to full screen mode, in which case DXGI providesIDXGISwapChain: ResizeTargetFunction. This function should be calledSetFullscreenStatePreviously called. Although these methods can be called in reverse order (firstSetFullscreenStateAnd then callResizeTarget. (This will also cause flickering, because DXGI may be forced between two modes ). Before callingSetFullscreenStateAnd then pass the resetDXGI_MODE_DESCMember variableRefreshRateCallResizeTargetIs a wise operation. This means that there is no operation in DXGI, but it can avoid the refresh rate problem discussed later.

 

In full screen mode, window Desktop Management (DWM) is invalid. DXGI will replace the Area Transport in window mode with a lighter method to present the content in the background buffer. This performance overhead is released. However, we have not talked about how to ensure that the regional transmission mode is replaced in a lightweight manner under certain conditions. In this case, the frontend buffer and backend buffer must be of the same size. If the application correctly processes the WM_SIZE message, this is obviously not a problem and the format must be identical.

 

For most applications, the problem is the refreshing rate.ResizeTargetThe update rate specified by this parameter must be used by the switch chain.IDXGIOutputUpdate rate,DXGI_MODE_DESCPassed inResizeTargetMember of the FunctionRefreshRateThe value is automatically reset by DXGI. Do not assume that the exact update rate value is supported. Generally, the developer selects 60Hz as the refresh rate and does not know that the refresh rate of the display is about 60,000/1,001Hz. If the update rate does not match the expected 60 HZ, DXGI forces Regional Transmission instead of full-screen lightweight transmission.

 

The last problem is that developers often face how to change the resolution in full screen mode. CallResizeTargetAndSetFullscreenStateSometimes it succeeds, but the full screen resolution is the desktop resolution. Similarly, developers may create a specified resolution in full screen mode. We found that DXGI will ignore the specified resolution we passed in. Unless otherwise specified, the full-screen switching link uses the default desktop resolution. When a full-screen resolution switching chain is created,DXGI_SWAP_CHAIN_DESCOfFlagsThe member struct must be setDXGI_SWAP_CHAIN_FLAG_ALLOW_MODE_SWITCHOverwrite the default parameters. This flag also needs to be passed inResizeTarget.