Full-screen DirectX* desktop apps using the Flip Presentation Model

Published:06/03/2013   Last Updated:06/03/2013

I've been messing around with the new Flip Presentation Model introduced in Windows* 8 (and on Windows* 7, with the Platform Update).  I'll have another post soon explaining my ulterior motives for wanting this, but for now here are a few notes on the Flip model that I collected along the way.

Full-screen games on the Windows* platform have traditionally run in exclusive mode, in which they take complete control of the display surface.  To interact with another application, the full-screen game would have to revert to a windowed mode or become minimized, or otherwise relinquish control of the display back to the OS.  This transition can be slow and disruptive to the game due to the number of resources to be reacquired or re-sized.

To avoid the trouble-prone transition in/out of exclusive mode, a few game developers have added the option to use full-screen borderless windowed (FSBW) mode.  In FSBW mode the foreground application's window border and decorations are hidden and the window client area is made the same size as the display surface.  FSBW mode is visually indistinguishable from full-screen exclusive mode, even though the OS compositor continues to 'own' the display and can draw another application window on top of the FSBW window.  This allows a second application (e.g. a chat window) to be popped-up over a running FSBW game with minimal latency or disruption to the game.  Until recently, having the compositor act as middle-man incurred an extra frame buffer copy, even if no other application window were visible, so there was some performance cost associated with FSBW mode.

In Windows* 8 a new feature called the flip presentation model has been added that can largely eliminate the performance cost of the compositor, by avoiding the frame buffer copy (in most cases).  All Windows Store* DirectX* apps use the flip presentation model by default.  For a desktop DirectX* application the flip model can be enabled by creating a swapchain with the DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL flag. Here are a few of the caveats when using the flip model, and some workarounds when filling out a DXGI_SWAP_CHAIN_DESC1 descriptor:

  • The swap chain format can only be one of DXGI_FORMAT_R16G16B16A16_FLOAT, DXGI_FORMAT_B8G8R8A8_UNORM, or DXGI_FORMAT_R8G8B8A8_UNORM.  Conspicuously absent are any gamma corrected sRGB formats.

    • Gamma correction solution: you can specify an sRGB format when you create the render target view, even though the swap chain format is not one of the *_TYPELESS formats.  This is a special exception added for flip mode.

  • The swap chain buffer count must be 2 or greater.  You avoid the copy at Present1() time by flipping between buffers, so there has to be more than one.

  • The SampleDesc.Count member must be 1; i.e. no multi-sample anti-aliasing.

    • Workaround: Create a multi-sampled render target, then do the resolve manually on copying to the back buffer.  (Disclaimer: I've seen a reference to this, but have not implemented it myself and have no details on it).

  • For best performance, set the swapchain resolution to match the display resolution, and set the Scaling member to DXGI_SCALING_NONE.  Note that this works only on Windows* 8.  On Windows* 7 (even with Platform Update) the only supported option is DXGI_SCALING_STRETCH.

As mentioned earlier, I have a project underway that requires FSBW mode, and I wanted to use the Flip Presentation Model to minimize any performance impact from FSBW.  I'll have another post shortly that describes that project, including sample source code demonstrating FSBW and the Flip swapchain.



Product and Performance Information


Performance varies by use, configuration and other factors. Learn more at www.Intel.com/PerformanceIndex.