Hi there,
I recently noted how my Windows 7 and Linux installations behaved differently when handling fullscreen game windows. On Windows, when I alt-tab from a fullscreen game to another window, there is a delay before reaching the other window, in which time the screen is completely black. On Linux, where I use Awesome window manager, switching away from a "workspace" with a fullscreen game on it has no latency whatsoever. However I did notice that leaving X and going to a TTY has a similar delay to the Windows scenario, which leads me to believe that on Linux the game's FB is being blitted into the framebuffer held by the window manager. So:
Does Windows switch the framebuffer set (or single framebuffer when there is no multiple-buffering/vsync) that is presented to the screen by the GPU when focusing on a fullscreen DirectX window?
Thanks for your time.
How are (focused) fullscreen DirectX windows presented to the screen?
Before WDDM 2.0 and Windows 10, full-screen application are in a "exclusive" mode. IIRC, exclusive mode comes from DirectDraw and an application in exclusive mode as an "exclusive" control of the video hardware, which means that other applications or system object cannot take control of the hardware adapter (ie allocating video memory, entering in full-screen mode). When you alt-tab from full-screen exclusive mode to desktop - or vice versa - there should be some type of context switch to change the owner of the video adapter which could cause a temporal black-screen on your system.
I am not sure how this concept has evolved through the different version of Windows and DirectX (so there could be some exception or less restriction on modern version of Windows... as example on Windows 8/8.1 the context switch should happen a little more graceful).
With WDDM 2.0 and Windows 10 the full-screen exclusive mode is no more, instead it is emulated: you can notice it in D3D12 application where the OS has the ability to pop-up notification on full-screen applications, moreover non D3D12 application should alt-tab a lot faster thanks to the new compositor. This means that on WDDM 2.0 fullscreen is more like a border-less window, the first is called by setFullscreenState(true), the second is created setting the fullscreen flag to "true" on the swap-chain descriptor.
If you want to have more details about full-screen mode and how frame buffers are handled, you should have a look at the DXGI programming guide (or DDraw/D3D9 programming guide for older applications).
I had the classic black screen flash on switching between fullscreen/windowed, it's caused by dxgi to say the least. Here's what I did to get a smoother transition between fullscreen/windowed.
//windowing code
- use raymond chen's reference: http://msdn.microsoft.com/en-us/library/windows/desktop/bb174578%28v=vs.85%29.aspx
//dx11 dxgi setup code...
DXGI_SWAP_CHAIN_DESC swapchaindesc;
....
swapchaindesc.Windowed = true; //DO NOT CHANGE FOR THE REMAINDER OF THE PROGRAM
IDXGIFactory* factory = ..;
factory->CreateSwapChain(device, swapchaindesc, ...);
I do not use ResizeTarget/ResizeBuffers as many other posts similar to this have recommended, but so far I havent encountered any problems yet.
