A display sub-system is often referred to as a video card, however, on some machines the display sub-system is part of the mother board.

To enumerate the display sub-systems, use . To get an interface to the adapter for a particular device, use . To create a software adapter, use .

implements base class functionality for several other interfaces: , , ,

SetPrivateData makes a copy of the specified data and stores it with the object.

Private data that SetPrivateData stores in the object occupies the same storage space as private data that is stored by associated Direct3D objects (for example, by a Microsoft Direct3D?11 device through or by a Direct3D?11 child device through ).

The debug layer reports memory leaks by outputting a list of object interface references along with their friendly names. The default friendly name is "<unnamed>". You can set the friendly name so that you can determine if the corresponding object interface reference caused the leak. To set the friendly name, use the SetPrivateData method and the well-known private data () that is in D3Dcommon.h. For example, to give pContext a friendly name of My name, use the following code:

 static const char c_szName[] = "My name";	
            hr = pContext->SetPrivateData( , sizeof( c_szName ) - 1, c_szName );	
            

You can use to track down memory leaks and understand performance characteristics of your applications. This information is reflected in the output of the debug layer that is related to memory leaks (ID3D11Debug::ReportLiveDeviceObjects) and with the event tracing for Windows events that we've added to Windows Developer Preview.

This API associates an interface reference with the object.

When the interface is set its reference count is incremented. When the data are overwritten (by calling SPD or SPDI with the same ) or the object is destroyed, ::Release() is called and the interface's reference count is decremented.

If the data returned is a reference to an , or one of its derivative classes, previously set by , then ::Release() must be called on the reference before the reference is freed to decrement the reference count.

When the EnumOutputs method succeeds and fills the ppOutput parameter with the address of the reference to the output interface, EnumOutputs increments the output interface's reference count. To avoid a memory leak, when you finish using the output interface, call the Release method to decrement the reference count.

EnumOutputs first returns the output on which the desktop primary is displayed. This adapter corresponds with an index of zero. EnumOutputs then returns other outputs.

Graphics applications can use the DXGI API to retrieve an accurate set of graphics memory values on systems that have WDDM drivers. The following are the critical steps involved.

• Graphics driver model determination ? Because DXGI is only available on systems with WDDM drivers, the application must first confirm the driver model by using the following API.

   HasWDDMDriver()	
              { LPDIRECT3DCREATE9EX pD3D9Create9Ex = null; HMODULE             hD3D9          = null; hD3D9 = LoadLibrary( L"d3d9.dll" ); if ( null == hD3D9 ) { return false; } // /*  Try to create IDirect3D9Ex interface (also known as a DX9L interface). This interface can only be created if the driver is a WDDM driver. */ // pD3D9Create9Ex = (LPDIRECT3DCREATE9EX) GetProcAddress( hD3D9, "Direct3DCreate9Ex" ); return pD3D9Create9Ex != null;	
              } 

• Retrieval of graphics memory values.? After the driver model is determined to be WDDM, the application can use the DirectX 10 or later API and DXGI to get the amount of graphics memory. After creating a Direct3D device the following code can be used to obtain a structure containing the amount of available graphics memory.

    * pDXGIDevice;	
              hr = g_pd3dDevice->QueryInterface(__uuidof(), (void **)&pDXGIDevice);	
               * pDXGIAdapter;	
              pDXGIDevice->GetAdapter(&pDXGIAdapter);	
               adapterDesc;	
              pDXGIAdapter->GetDesc(&adapterDesc); 

Note??You can use CheckInterfaceSupport only to check whether a Direct3D 10.x interface is supported, and only on Windows Vista SP1 and later versions of the operating system. If you try to use CheckInterfaceSupport to check whether a Direct3D 11.x and later version interface is supported, CheckInterfaceSupport returns . Therefore, do not use CheckInterfaceSupport. Instead, to verify whether the operating system supports a particular interface, try to create the interface. For example, if you call the method and it fails, the operating system does not support the interface.

Graphics applications can use the DXGI API to retrieve an accurate set of graphics memory values on systems that have WDDM drivers. The following are the critical steps involved.

• Graphics driver model determination ? Because DXGI is only available on systems with WDDM drivers, the application must first confirm the driver model by using the following API.

   HasWDDMDriver()	
              { LPDIRECT3DCREATE9EX pD3D9Create9Ex = null; HMODULE             hD3D9          = null; hD3D9 = LoadLibrary( L"d3d9.dll" ); if ( null == hD3D9 ) { return false; } // /*  Try to create IDirect3D9Ex interface (also known as a DX9L interface). This interface can only be created if the driver is a WDDM driver. */ // pD3D9Create9Ex = (LPDIRECT3DCREATE9EX) GetProcAddress( hD3D9, "Direct3DCreate9Ex" ); return pD3D9Create9Ex != null;	
              } 

• Retrieval of graphics memory values.? After the driver model is determined to be WDDM, the application can use the DirectX 10 or later API and DXGI to get the amount of graphics memory. After creating a Direct3D device the following code can be used to obtain a structure containing the amount of available graphics memory.

    * pDXGIDevice;	
              hr = g_pd3dDevice->QueryInterface(__uuidof(), (void **)&pDXGIDevice);	
               * pDXGIAdapter;	
              pDXGIDevice->GetAdapter(&pDXGIAdapter);	
               adapterDesc;	
              pDXGIAdapter->GetDesc(&adapterDesc); 

An image-data object is a 2D section of memory, commonly called a surface. To get the surface from an output, call . Then, call QueryInterface on the object that returns to retrieve the interface.

Any object that supports also supports .

The runtime automatically creates an interface when it creates a Direct3D resource object that represents a surface. For example, the runtime creates an interface when you call to create a 2D texture. To retrieve the interface that represents the 2D texture surface, call ID3D11Texture2D::QueryInterface. In this call, you must pass the identifier of . If the 2D texture has only a single MIP-map level and does not consist of an array of textures, QueryInterface succeeds and returns a reference to the interface reference. Otherwise, QueryInterface fails and does not return the reference to .

You can call the method to create an interface that refers to one subresource of a stereo resource.

This interface is not supported by DXGI 1.0, which shipped in Windows?Vista and Windows Server?2008. DXGI 1.1 support is required, which is available on Windows?7, Windows Server?2008?R2, and as an update to Windows?Vista with Service Pack?2 (SP2) (KB 971644) and Windows Server?2008 (KB 971512).

An image-data object is a 2D section of memory, commonly called a surface. To get the surface from an output, call . Then, call QueryInterface on the object that returns to retrieve the interface.

Any object that supports also supports .

The runtime automatically creates an interface when it creates a Direct3D resource object that represents a surface. For example, the runtime creates an interface when you call or ID3D10Device::CreateTexture2D to create a 2D texture. To retrieve the interface that represents the 2D texture surface, call ID3D11Texture2D::QueryInterface or ID3D10Texture2D::QueryInterface. In this call, you must pass the identifier of . If the 2D texture has only a single MIP-map level and does not consist of an array of textures, QueryInterface succeeds and returns a reference to the interface reference. Otherwise, QueryInterface fails and does not return the reference to .

An image-data object is a 2D section of memory, commonly called a surface. To get the surface from an output, call .

The runtime automatically creates an interface when it creates a Direct3D resource object that represents a surface. For example, the runtime creates an interface when you call or ID3D10Device::CreateTexture2D to create a 2D texture. To retrieve the interface that represents the 2D texture surface, call ID3D11Texture2D::QueryInterface or ID3D10Texture2D::QueryInterface. In this call, you must pass the identifier of . If the 2D texture has only a single MIP-map level and does not consist of an array of textures, QueryInterface succeeds and returns a reference to the interface reference. Otherwise, QueryInterface fails and does not return the reference to .

The type of interface that is returned can be any interface published by the device. For example, it could be an * called pDevice, and therefore the REFIID would be obtained by calling __uuidof(pDevice).

Use to access a surface from the CPU. To release a mapped surface (and allow GPU access) call .

This method is not supported by DXGI 1.0, which shipped in Windows?Vista and Windows Server?2008. DXGI 1.1 support is required, which is available on Windows?7, Windows Server?2008?R2, and as an update to Windows?Vista with Service Pack?2 (SP2) (KB 971644) and Windows Server?2008 (KB 971512).

After you use the GetDC method to retrieve a DC, you can render to the DXGI surface by using GDI. The GetDC method readies the surface for GDI rendering and allows inter-operation between DXGI and GDI technologies.

Keep the following in mind when using this method:

• You must create the surface by using the flag for a surface or by using the flag for swap chains, otherwise this method fails.
• You must release the device and call the method before you issue any new Direct3D commands.
• This method fails if an outstanding DC has already been created by this method.
• The format for the surface or swap chain must be or .
• On GetDC, the render target in the output merger of the Direct3D pipeline is unbound from the surface. You must call the method on the device prior to Direct3D rendering after GDI rendering.
• Prior to resizing buffers you must release all outstanding DCs.

You can also call GetDC on the back buffer at index 0 of a swap chain by obtaining an from the swap chain. The following code illustrates the process.

 * g_pSwapChain = null;	
            * g_pSurface1 = null;	
            ...	
            //Setup the device and and swapchain	
            g_pSwapChain->GetBuffer(0, __uuidof(), (void**) &g_pSurface1);	
            g_pSurface1->GetDC( , &g_hDC );	
            ...      	
            //Draw on the DC using GDI	
            ...	
            //When finish drawing release the DC	
            g_pSurface1->ReleaseDC( null ); 

This method is not supported by DXGI 1.0, which shipped in Windows?Vista and Windows Server?2008. DXGI 1.1 support is required, which is available on Windows?7, Windows Server?2008?R2, and as an update to Windows?Vista with Service Pack?2 (SP2) (KB 971644) and Windows Server?2008 (KB 971512).

Use the ReleaseDC method to release the DC and indicate that your application finished all GDI rendering to this surface. You must call the ReleaseDC method before you can use Direct3D to perform additional rendering.

Prior to resizing buffers you must release all outstanding DCs.

For subresource surface objects that the method creates, GetResource simply returns the values that were used to create the subresource surface.

Current objects that implement are either resources or views. GetResource for these objects returns ?this? or the resource that supports the view respectively. In this situation, the subresource index is 0.

CreateSharedHandle only returns the NT handle when you created the resource as shared and specified that it uses NT handles (that is, you set the and flags). If you created the resource as shared and specified that it uses NT handles, you must use CreateSharedHandle to get a handle for sharing. In this situation, you can't use the method because it will fail.

You can pass the handle that CreateSharedHandle returns in a call to the method to give a device access to a shared resource that you created on a different device.

Because the handle that CreateSharedHandle returns is an NT handle, you can use the handle with CloseHandle, DuplicateHandle, and so on. You can call CreateSharedHandle only once for a shared resource; later calls fail. If you need more handles to the same shared resource, call DuplicateHandle. When you no longer need the shared resource handle, call CloseHandle to close the handle, in order to avoid memory leaks.

If you pass a name for the resource to lpName when you call CreateSharedHandle to share the resource, you can subsequently pass this name in a call to the method to give another device access to the shared resource. If you use a named resource, a malicious user can use this named resource before you do and prevent your app from starting. To prevent this situation, create a randomly named resource and store the name so that it can only be obtained by an authorized user. Alternatively, you can use a file for this purpose. To limit your app to one instance per user, create a locked file in the user's profile directory.

If you created the resource as shared and did not specify that it uses NT handles, you cannot use CreateSharedHandle to get a handle for sharing because CreateSharedHandle will fail.

To find out what type of memory a resource is currently located in, use . To share resources between processes, use ID3D10Device::OpenSharedResource. For information about how to share resources between multiple Windows graphics APIs, including Direct3D 11, Direct2D, Direct3D 10, and Direct3D 9Ex, see Surface Sharing Between Windows Graphics APIs.

You can retrieve the interface from any video memory resource that you create from a Direct3D 10 and later function. Any Direct3D object that supports ID3D10Resource or also supports . For example, the Direct3D 2D texture object that you create from supports . You can call QueryInterface on the 2D texture object () to retrieve the interface. For example, to retrieve the interface from the 2D texture object, use the following code.

 * pDXGIResource;	
            hr = g_pd3dTexture2D->QueryInterface(__uuidof(), (void **)&pDXGIResource);	
            

You can pass the handle that GetSharedHandle returns in a call to the method to give a device access to a shared resource that you created on a different device.

GetSharedHandle doesn't always return a handle. GetSharedHandle only returns the handle when you created the resource as shared (that is, you set the or flag).

The handle that GetSharedHandle returns is not an NT handle. Therefore, don't use the handle with CloseHandle, DuplicateHandle, and so on. The creator of a shared resource must not destroy the resource until all entities that opened the resource have destroyed the resource. The validity of the handle is tied to the lifetime of the underlying video memory. If no resource objects exist on any devices that refer to this resource, the handle is no longer valid. To extend the lifetime of the handle and video memory, you must open the shared resource on a device.

The eviction priority is a memory-management variable that is used by DXGI for determining how to populate overcommitted memory.

You can set priority levels other than the defined values when appropriate. For example, you can set a resource with a priority level of 0x78000001 to indicate that the resource is slightly above normal.

The eviction priority is a memory-management variable that is used by DXGI to determine how to manage overcommitted memory.

Priority levels other than the defined values are used when appropriate. For example, a resource with a priority level of 0x78000001 indicates that the resource is slightly above normal.

You can pass the handle that GetSharedHandle returns in a call to the method to give a device access to a shared resource that you created on a different device.

GetSharedHandle doesn't always return a handle. GetSharedHandle only returns the handle when you created the resource as shared (that is, you set the or flag).

The handle that GetSharedHandle returns is not an NT handle. Therefore, don't use the handle with CloseHandle, DuplicateHandle, and so on. The creator of a shared resource must not destroy the resource until all entities that opened the resource have destroyed the resource. The validity of the handle is tied to the lifetime of the underlying video memory. If no resource objects exist on any devices that refer to this resource, the handle is no longer valid. To extend the lifetime of the handle and video memory, you must open the shared resource on a device.

The eviction priority is a memory-management variable that is used by DXGI to determine how to manage overcommitted memory.

Priority levels other than the defined values are used when appropriate. For example, a resource with a priority level of 0x78000001 indicates that the resource is slightly above normal.

Subresource surface objects implement the interface, which inherits from and indirectly . Therefore, the GDI-interoperable methods of work if the original resource interface object was created with the GDI-interoperable flag ().

CreateSubresourceSurface creates a subresource surface that is based on the resource interface on which CreateSubresourceSurface is called. For example, if the original resource interface object is a 2D texture, the created subresource surface is also a 2D texture.

You can use CreateSubresourceSurface to create parts of a stereo resource so you can use Direct2D on either the left or right part of the stereo resource.

CreateSharedHandle only returns the NT handle when you created the resource as shared and specified that it uses NT handles (that is, you set the and flags). If you created the resource as shared and specified that it uses NT handles, you must use CreateSharedHandle to get a handle for sharing. In this situation, you can't use the method because it will fail.

You can pass the handle that CreateSharedHandle returns in a call to the method to give a device access to a shared resource that you created on a different device.

Because the handle that CreateSharedHandle returns is an NT handle, you can use the handle with CloseHandle, DuplicateHandle, and so on. You can call CreateSharedHandle only once for a shared resource; later calls fail. If you need more handles to the same shared resource, call DuplicateHandle. When you no longer need the shared resource handle, call CloseHandle to close the handle, in order to avoid memory leaks.

If you pass a name for the resource to lpName when you call CreateSharedHandle to share the resource, you can subsequently pass this name in a call to the method to give another device access to the shared resource. If you use a named resource, a malicious user can use this named resource before you do and prevent your app from starting. To prevent this situation, create a randomly named resource and store the name so that it can only be obtained by an authorized user. Alternatively, you can use a file for this purpose. To limit your app to one instance per user, create a locked file in the user's profile directory.

If you created the resource as shared and did not specify that it uses NT handles, you cannot use CreateSharedHandle to get a handle for sharing because CreateSharedHandle will fail.

This interface provides the native implementation of the Windows::UI::Xaml::Media::Imaging::VirtualSurfaceImageSource Windows runtime type. To obtain a reference to , you must cast a VirtualSurfaceImageSource instance to IInspectable or , and call QueryInterface.

 Microsoft::WRL::ComPtr<>	m_vsisNative;	
            // ...	
            IInspectable* vsisInspectable = (IInspectable*) reinterpret_cast<IInspectable*>(virtualSurfaceImageSource);	
            vsisInspectable->QueryInterface(__uuidof(), (void **)&m_vsisNative) 

This interface provides the native implementation of the Windows::UI::Xaml::Media::Imaging::VirtualSurfaceImageSource Windows runtime type. To obtain a reference to , you must cast a VirtualSurfaceImageSource instance to IInspectable or , and call QueryInterface.

 Microsoft::WRL::ComPtr<>	m_vsisNative;	
            // ...	
            IInspectable* vsisInspectable = (IInspectable*) reinterpret_cast<IInspectable*>(virtualSurfaceImageSource);	
            vsisInspectable->QueryInterface(__uuidof(), (void **)&m_vsisNative) 

This interface provides the native implementation of the Windows::UI::Xaml::Media::Imaging::VirtualSurfaceImageSource Windows runtime type. To obtain a reference to , you must cast a VirtualSurfaceImageSource instance to IInspectable or , and call QueryInterface.

 Microsoft::WRL::ComPtr<>	m_vsisNative;	
            // ...	
            IInspectable* vsisInspectable = (IInspectable*) reinterpret_cast<IInspectable*>(virtualSurfaceImageSource);	
            vsisInspectable->QueryInterface(__uuidof(), (void **)&m_vsisNative) 

This interface provides the native implementation of the Windows::UI::Xaml::Media::Imaging::VirtualSurfaceImageSource Windows runtime type. To obtain a reference to , you must cast a VirtualSurfaceImageSource instance to IInspectable or , and call QueryInterface.

 Microsoft::WRL::ComPtr<>	m_vsisNative;	
            // ...	
            IInspectable* vsisInspectable = (IInspectable*) reinterpret_cast<IInspectable*>(virtualSurfaceImageSource);	
            vsisInspectable->QueryInterface(__uuidof(), (void **)&m_vsisNative) 

This interface provides the native implementation of the Windows::UI::Xaml::Media::Imaging::VirtualSurfaceImageSource Windows runtime type. To obtain a reference to , you must cast a VirtualSurfaceImageSource instance to IInspectable or , and call QueryInterface.

 Microsoft::WRL::ComPtr<>	m_vsisNative;	
            // ...	
            IInspectable* vsisInspectable = (IInspectable*) reinterpret_cast<IInspectable*>(virtualSurfaceImageSource);	
            vsisInspectable->QueryInterface(__uuidof(), (void **)&m_vsisNative) 

This interface provides the native implementation of the Windows::UI::Xaml::Media::Imaging::VirtualSurfaceImageSource Windows runtime type. To obtain a reference to , you must cast a VirtualSurfaceImageSource instance to IInspectable or , and call QueryInterface.

 Microsoft::WRL::ComPtr<>	m_vsisNative;	
            // ...	
            IInspectable* vsisInspectable = (IInspectable*) reinterpret_cast<IInspectable*>(virtualSurfaceImageSource);	
            vsisInspectable->QueryInterface(__uuidof(), (void **)&m_vsisNative) 

This interface is implemented by the developer to provide specific drawing behaviors for updates to a VirtualSurfaceImageSource. Classes that implement this interface are provided to the , which calls the UpdatesNeeded method implementation whenever an update is requested.

The interface is designed for use by DXGI objects that need access to other DXGI objects. This interface is useful to applications that do not use Direct3D to communicate with DXGI.

The object returned by the Direct3D create device functions implements the interface and can be queried for the device's corresponding interface. To retrieve the interface of a Direct3D device the following code can be used.

 * pDXGIDevice;	
            hr = g_pd3dDevice->QueryInterface(__uuidof(), (void **)&pDXGIDevice);	
            

If the GetAdapter method succeeds, the reference count on the adapter interface will be incremented. To avoid a memory leak, be sure to release the interface when you are finished using it.

The CreateSurface method creates a buffer to exchange data between one or more devices. It is used internally, and you should not directly call it.

The runtime automatically creates an interface when it creates a Direct3D resource object that represents a surface. For example, the runtime creates an interface when it calls or ID3D10Device::CreateTexture2D to create a 2D texture. To retrieve the interface that represents the 2D texture surface, call ID3D11Texture2D::QueryInterface or ID3D10Texture2D::QueryInterface. In this call, you must pass the identifier of . If the 2D texture has only a single MIP-map level and does not consist of an array of textures, QueryInterface succeeds and returns a reference to the interface reference. Otherwise, QueryInterface fails and does not return the reference to .

The information returned by the pResidencyStatus argument array describes the residency status at the time that the QueryResourceResidency method was called. Note that the residency status will constantly change.

If you call the QueryResourceResidency method during a device removed state, the pResidencyStatus argument will return the flag.

Note??This method should not be called every frame as it incurs a non-trivial amount of overhead.

The information returned by the pResidencyStatus argument array describes the residency status at the time that the QueryResourceResidency method was called. Note that the residency status will constantly change.

If you call the QueryResourceResidency method during a device removed state, the pResidencyStatus argument will return the flag.

Note??This method should not be called every frame as it incurs a non-trivial amount of overhead.

The values for the Priority parameter function as follows:

• Positive values increase the likelihood that the GPU scheduler will grant GPU execution cycles to the device when rendering.
• Negative values lessen the likelihood that the device will receive GPU execution cycles when devices compete for them.
• The device is guaranteed to receive some GPU execution cycles at all settings.

To use the SetGPUThreadPriority method, you should have a comprehensive understanding of GPU scheduling. You should profile your application to ensure that it behaves as intended. If used inappropriately, the SetGPUThreadPriority method can impede rendering speed and result in a poor user experience.

If the GetAdapter method succeeds, the reference count on the adapter interface will be incremented. To avoid a memory leak, be sure to release the interface when you are finished using it.

Create a factory by calling CreateDXGIFactory.

Because a Direct3D device can be created without creating a swap chain, you might need to retrieve the factory that is used to create the device in order to create a swap chain. This can be accomplished by requesting the interface from the Direct3D device and then using to locate the factory. The following code illustrates the process.

 * pDXGIDevice;	
            hr = g_pd3dDevice->QueryInterface(__uuidof(), (void **)&pDXGIDevice);  * pDXGIAdapter;	
            hr = pDXGIDevice->GetParent(__uuidof(), (void **)&pDXGIAdapter);  * pIDXGIFactory;	
            pDXGIAdapter->GetParent(__uuidof(), (void **)&pIDXGIFactory);	
            

See for a diagram of the relationship between DXGI objects.

When you create a factory, the factory enumerates the set of adapters that are available in the system. Therefore, if you change the adapters in a system, you must destroy and recreate the object. The number of adapters in a system changes when you add or remove a display card, or dock or undock a laptop.

When the EnumAdapters method succeeds and fills the ppAdapter parameter with the address of the reference to the adapter interface, EnumAdapters increments the adapter interface's reference count. When you finish using the adapter interface, call the Release method to decrement the reference count before you destroy the reference.

EnumAdapters first returns the local adapter with the output on which the desktop primary is displayed. This adapter corresponds with an index of zero. EnumAdapters then returns other adapters with outputs.

The combination of WindowHandle and Flags informs DXGI to stop monitoring window messages for the previously-associated window.

If the application switches to full-screen mode, DXGI will choose a full-screen resolution to be the smallest supported resolution that is larger or the same size as the current back buffer size.

Applications can make some changes to make the transition from windowed to full screen more efficient. For example, on a WM_SIZE message, the application should release any outstanding swap-chain back buffers, call , then re-acquire the back buffers from the swap chain(s). This gives the swap chain(s) an opportunity to resize the back buffers, and/or recreate them to enable full-screen flipping operation. If the application does not perform this sequence, DXGI will still make the full-screen/windowed transition, but may be forced to use a stretch operation (since the back buffers may not be the correct size), which may be less efficient. Even if a stretch is not required, presentation may not be optimal because the back buffers might not be directly interchangeable with the front buffer. Thus, a call to ResizeBuffers on WM_SIZE is always recommended, since WM_SIZE is always sent during a fullscreen transition.

While windowed, the application can, if it chooses, restrict the size of its window's client area to sizes to which it is comfortable rendering. A fully flexible application would make no such restriction, but UI elements or other design considerations can, of course, make this flexibility untenable. If the application further chooses to restrict its window's client area to just those that match supported full-screen resolutions, the application can field WM_SIZING, then check against . If a matching mode is found, allow the resize. (The can be retrieved from . Absent subsequent changes to desktop topology, this will be the same output that will be chosen when alt-enter is fielded and fullscreen mode is begun for that swap chain.)

Applications that want to handle mode changes or Alt+Enter themselves should call MakeWindowAssociation with the flag after swap chain creation. The WindowHandle argument, if non-null, specifies that the application message queues will not be handled by the DXGI runtime for all swap chains of a particular target . Calling MakeWindowAssociation with the flag after swapchain creation ensures that DXGI will not interfere with application's handling of window mode changes or Alt+Enter.

If a Metro style app calls MakeWindowAssociation, it fails with .

A Microsoft Win32 application can use MakeWindowAssociation to control full-screen transitions through the Alt+Enter key combination and print screen behavior for full screen. For Metro style apps, because DXGI cannot perform full-screen transitions, Metro style app have no way to control full-screen transitions.

If a Metro style app calls GetWindowAssociation, it fails with .

If you attempt to create a swap chain in full-screen mode, and full-screen mode is unavailable, the swap chain will be created in windowed mode and will be returned.

If the buffer width or the buffer height is zero, the sizes will be inferred from the output window size in the swap-chain description.

Because the target output cannot be chosen explicitly when the swap-chain is created, you should not create a full-screen swap chain. This can reduce presentation performance if the swap chain size and the output window size do not match. Here are two ways to ensure that the sizes match:

• Create a windowed swap chain and then set it full-screen using .
• Save a reference to the swap chain immediately after creation, and use it to get the output window size during a WM_SIZE event. Then resize the swap chain buffers (with ) during the transition from windowed to full-screen.

If the swap chain is in full-screen mode, before you release it you must use SetFullscreenState to switch it to windowed mode. For more information about releasing a swap chain, see the "Destroying a Swap Chain" section of DXGI Overview.

You can specify and values in the swap-chain description that pDesc points to. These values allow you to use features like flip-model presentation and content protection by using pre-Windows Developer Preview APIs.

However, to use stereo presentation and to change resize behavior for the flip model, applications must use the method. Otherwise, the back-buffer contents implicitly scale to fit the presentation target size; that is, you can't turn off scaling.

If a Metro style app calls CreateSwapChain with full screen specified, CreateSwapChain fails.

Metro style apps call the IDXGIFactory2::CreateSwapChainForImmersiveWindow method to create a swap chain.

A software adapter is a DLL that implements the entirety of a device driver interface, plus emulation, if necessary, of kernel-mode graphics components for Windows. Details on implementing a software adapter can be found in the Windows Vista Driver Development Kit. This is a very complex development task, and is not recommended for general readers.

Calling this method will increment the module's reference count by one. The reference count can be decremented by calling FreeLibrary.

The typical calling scenario is to call LoadLibrary, pass the handle to CreateSoftwareAdapter, then immediately call FreeLibrary on the DLL and forget the DLL's HMODULE. Since the software adapter calls FreeLibrary when it is destroyed, the lifetime of the DLL will now be owned by the adapter, and the application is free of any further consideration of its lifetime.

This interface is not supported by DXGI 1.0, which shipped in Windows?Vista and Windows Server?2008. DXGI 1.1 support is required, which is available on Windows?7, Windows Server?2008?R2, and as an update to Windows?Vista with Service Pack?2 (SP2) (KB 971644) and Windows Server?2008 (KB 971512).

To create a factory, call the CreateDXGIFactory1 function.

This method is not supported by DXGI 1.0, which shipped in Windows?Vista and Windows Server?2008. DXGI 1.1 support is required, which is available on Windows?7, Windows Server?2008?R2, and as an update to Windows?Vista with Service Pack?2 (SP2) (KB 971644) and Windows Server?2008 (KB 971512).

When you create a factory, the factory enumerates the set of adapters that are available in the system. Therefore, if you change the adapters in a system, you must destroy and recreate the object. The number of adapters in a system changes when you add or remove a display card, or dock or undock a laptop.

When the EnumAdapters1 method succeeds and fills the ppAdapter parameter with the address of the reference to the adapter interface, EnumAdapters1 increments the adapter interface's reference count. When you finish using the adapter interface, call the Release method to decrement the reference count before you destroy the reference.

EnumAdapters1 first returns the local adapter with the output on which the desktop primary is displayed. This adapter corresponds with an index of zero. EnumAdapters1 next returns other adapters with outputs. EnumAdapters1 finally returns adapters without outputs.

This method is not supported by DXGI 1.0, which shipped in Windows?Vista and Windows Server?2008. DXGI 1.1 support is required, which is available on Windows?7, Windows Server?2008?R2, and as an update to Windows?Vista with Service Pack?2 (SP2) (KB 971644) and Windows Server?2008 (KB 971512).

This method is not supported by DXGI 1.0, which shipped in Windows?Vista and Windows Server?2008. DXGI 1.1 support is required, which is available on Windows?7, Windows Server?2008?R2, and as an update to Windows?Vista with Service Pack?2 (SP2) (KB 971644) and Windows Server?2008 (KB 971512).

The enumerated type is used by the Flags member of the or structure to identify the type of DXGI adapter.

For more information about alpha mode, see .

You call the method to retrieve the granularity level at which the GPU can be preempted from performing its current compute task. The operating system specifies the compute granularity level in the ComputePreemptionGranularity member of the structure.

A few formats have additional restrictions.

1. A resource declared with the DXGI_FORMAT_R32G32B32 family of formats cannot be used simultaneously for vertex and texture data. That is, you may not create a buffer resource with the DXGI_FORMAT_R32G32B32 family of formats that uses any of the following bind flags: D3D10_BIND_VERTEX_BUFFER, D3D10_BIND_INDEX_BUFFER, D3D10_BIND_CONSTANT_BUFFER, or D3D10_BIND_STREAM_OUTPUT (see D3D10_BIND_FLAG).
2. is designed specifically for text filtering, and must be used with a format-specific, configurable 8x8 filter mode. When calling an HLSL sampling function using this format, the address offset parameter must be set to (0,0).
3. A resource using a sub-sampled format (such as DXGI_FORMAT_R8G8_B8G8) must have a size that is a multiple of 2 in the x dimension.
4. Format is not available in Direct3D 10 and Direct3D 10.1

The following topics provide lists of the formats that particular hardware feature levels support:

• Hardware Support for Direct3D 11.1 Formats
• Hardware Support for Direct3D 11 Formats
• Hardware Support for Direct3D 10.1 Formats
• Hardware Support for Direct3D 10 Formats
• Hardware Support for Direct3D 10Level9 Formats

For a list of the DirectXMath types that map to values, see DirectXMath Library Internals.

Each enumeration value contains a format modifier which describes the data type.

 , , , ,	
            

?

Direct3D 10 offers new data compression formats for compressing high-dynamic range (HDR) lighting data, normal maps and heightfields to a fraction of their original size. These compression types include:

• Shared-Exponent high-dynamic range (HDR) format (RGBE)
• New Block-Compressed 1-2 channel UNORM/SNORM formats

The block compression formats can be used for any of the 2D or 3D texture types ( Texture2D, Texture2DArray, Texture3D, or TextureCube) including mipmap surfaces. The block compression techniques require texture dimensions to be a multiple of 4 (since the implementation compresses on blocks of 4x4 texels). In the texture sampler, compressed formats are always decompressed before texture filtering.

You call the method to retrieve the granularity level at which the GPU can be preempted from performing its current graphics rendering task. The operating system specifies the graphics granularity level in the GraphicsPreemptionGranularity member of the structure.

The following figure shows granularity of graphics rendering tasks.

Priority determines how likely the operating system is to discard an offered resource. Resources offered with lower priority are discarded first.

The value is supported only for flip presentation model swap chains that you create with the value. You pass these values in a call to , , or .

This enumeration is used by the structure and the method.

This enumeration is also used by the structure.

Swap chains that you create in full-screen mode with the method behave as if is set even though the flag is not set. That is, presented content is not accessible by remote access or through the desktop duplication APIs.

Swap chains that you create with the , IDXGIFactory2::CreateSwapChainForImmersiveWindow, and IDXGIFactory2::CreateSwapChainForCompositionSurface methods are not protected if is not set and are protected if is set. When swap chains are protected, screen scraping is prevented and, in full-screen mode, presented content is not accessible through the desktop duplication APIs.

This enumeration is used by the structure.

This enumeration is also used by the structure.

The primary difference between presentation models is how back-buffer contents get to the Desktop Window Manager (DWM) for composition. In the bitblt model, which is used with the and values, contents of the back buffer get copied into the redirection surface on each call to . In the flip model, which is used with the value, all back buffers are shared with the DWM. Therefore, the DWM can compose straight from those back buffers without any additional copy operations. In general, the flip model is the more efficient model. The flip model also provides more features, such as enhanced present statistics.

Regardless of whether the flip model is more efficient, an application still might choose the bitblt model for the following reasons:

• The bitblt model is the only way to mix GDI and DirectX presentation.

  In the flip model, the application must create the swap chain with , and then must use GetDC on the back buffer explicitly. After the first successful call to on a flip-model swap chain, GDI no longer works with the that is associated with that swap chain, even after the destruction of the swap chain. This restriction even extends to methods like ScrollWindowEx.

• The flip model requires at least three window-sized buffers if the application uses child windows. For the bitblt model, this minimum is two buffers.

Use a DXGI 1.1 factory to generate objects that enumerate adapters, create swap chains, and associate a window with the alt+enter key sequence for toggling to and from the full-screen display mode.

If the CreateDXGIFactory1 function succeeds, the reference count on the interface is incremented. To avoid a memory leak, when you finish using the interface, call the IDXGIFactory1::Release method to release the interface.

This entry point is not supported by DXGI 1.0, which shipped in Windows?Vista and Windows Server?2008. DXGI 1.1 support is required, which is available on Windows?7, Windows Server?2008?R2, and as an update to Windows?Vista with Service Pack?2 (SP2) (KB 971644) and Windows Server?2008 (KB 971512).

Note??Do not mix the use of DXGI 1.0 () and DXGI 1.1 () in an application. Use or , but not both in an application.

This interface is not supported by DXGI 1.0, which shipped in Windows?Vista and Windows Server?2008. DXGI 1.1 support is required, which is available on Windows?7, Windows Server?2008?R2, and as an update to Windows?Vista with Service Pack?2 (SP2) (KB 971644) and Windows Server?2008 (KB 971512).

A display sub-system is often referred to as a video card, however, on some machines the display sub-system is part of the mother board.

To enumerate the display sub-systems, use . To get an interface to the adapter for a particular device, use . To create a software adapter, use .

This method is not supported by DXGI 1.0, which shipped in Windows?Vista and Windows Server?2008. DXGI 1.1 support is required, which is available on Windows?7, Windows Server?2008?R2, and as an update to Windows?Vista with Service Pack?2 (SP2) (KB 971644) and Windows Server?2008 (KB 971512).

Use the GetDesc1 method to get a DXGI 1.1 description of an adapter. To get a DXGI 1.0 description, use the method.

This method is not supported by DXGI 1.0, which shipped in Windows?Vista and Windows Server?2008. DXGI 1.1 support is required, which is available on Windows?7, Windows Server?2008?R2, and as an update to Windows?Vista with Service Pack?2 (SP2) (KB 971644) and Windows Server?2008 (KB 971512).

Use the GetDesc1 method to get a DXGI 1.1 description of an adapter. To get a DXGI 1.0 description, use the method.

Use the GetDesc2 method to get a DXGI 1.2 description of an adapter. To get a DXGI 1.1 description, use the method. To get a DXGI 1.0 description, use the method.

The Windows Display Driver Model (WDDM) scheduler can preempt the GPU's execution of application tasks. The granularity at which the GPU can be preempted from performing its current task in the WDDM 1.1 or earlier driver model is a direct memory access (DMA) buffer for graphics tasks or a compute packet for compute tasks. The GPU can switch between tasks only after it completes the currently executing unit of work, a DMA buffer or a compute packet.

A DMA buffer is the largest independent unit of graphics work that the WDDM scheduler can submit to the GPU. This buffer contains a set of GPU instructions that the WDDM driver and GPU use. A compute packet is the largest independent unit of compute work that the WDDM scheduler can submit to the GPU. A compute packet contains dispatches (for example, calls to the method), which contain thread groups. The WDDM 1.2 or later driver model allows the GPU to be preempted at finer granularity levels than a DMA buffer or compute packet. You can use the GetDesc2 method to retrieve the granularity levels for graphics and compute tasks.

Use the GetDesc2 method to get a DXGI 1.2 description of an adapter. To get a DXGI 1.1 description, use the method. To get a DXGI 1.0 description, use the method.

The Windows Display Driver Model (WDDM) scheduler can preempt the GPU's execution of application tasks. The granularity at which the GPU can be preempted from performing its current task in the WDDM 1.1 or earlier driver model is a direct memory access (DMA) buffer for graphics tasks or a compute packet for compute tasks. The GPU can switch between tasks only after it completes the currently executing unit of work, a DMA buffer or a compute packet.

A DMA buffer is the largest independent unit of graphics work that the WDDM scheduler can submit to the GPU. This buffer contains a set of GPU instructions that the WDDM driver and GPU use. A compute packet is the largest independent unit of compute work that the WDDM scheduler can submit to the GPU. A compute packet contains dispatches (for example, calls to the method), which contain thread groups. The WDDM 1.2 or later driver model allows the GPU to be preempted at finer granularity levels than a DMA buffer or compute packet. You can use the GetDesc2 method to retrieve the granularity levels for graphics and compute tasks.

Use the GetDesc2 method to get a DXGI 1.2 description of an adapter. To get a DXGI 1.1 description, use the method. To get a DXGI 1.0 description, use the method.

The Windows Display Driver Model (WDDM) scheduler can preempt the GPU's execution of application tasks. The granularity at which the GPU can be preempted from performing its current task in the WDDM 1.1 or earlier driver model is a direct memory access (DMA) buffer for graphics tasks or a compute packet for compute tasks. The GPU can switch between tasks only after it completes the currently executing unit of work, a DMA buffer or a compute packet.

A DMA buffer is the largest independent unit of graphics work that the WDDM scheduler can submit to the GPU. This buffer contains a set of GPU instructions that the WDDM driver and GPU use. A compute packet is the largest independent unit of compute work that the WDDM scheduler can submit to the GPU. A compute packet contains dispatches (for example, calls to the method), which contain thread groups. The WDDM 1.2 or later driver model allows the GPU to be preempted at finer granularity levels than a DMA buffer or compute packet. You can use the GetDesc2 method to retrieve the granularity levels for graphics and compute tasks.

This interface is not supported by DXGI 1.0, which shipped in Windows?Vista and Windows Server?2008. DXGI 1.1 support is required, which is available on Windows?7, Windows Server?2008?R2, and as an update to Windows?Vista with Service Pack?2 (SP2) (KB 971644) and Windows Server?2008 (KB 971512).

The interface is designed for use by DXGI objects that need access to other DXGI objects. This interface is useful to applications that do not use Direct3D to communicate with DXGI.

This method is not supported by DXGI 1.0, which shipped in Windows?Vista and Windows Server?2008. DXGI 1.1 support is required, which is available on Windows?7, Windows Server?2008?R2, and as an update to Windows?Vista with Service Pack?2 (SP2) (KB 971644) and Windows Server?2008 (KB 971512).

Frame latency is the number of frames that are allowed to be stored in a queue before submission for rendering. Latency is often used to control how the CPU chooses between responding to user input and frames that are in the render queue. It is often beneficial for applications that have no user input (for example, video playback) to queue more than 3 frames of data.

This method is not supported by DXGI 1.0, which shipped in Windows?Vista and Windows Server?2008. DXGI 1.1 support is required, which is available on Windows?7, Windows Server?2008?R2, and as an update to Windows?Vista with Service Pack?2 (SP2) (KB 971644) and Windows Server?2008 (KB 971512).

Frame latency is the number of frames that are allowed to be stored in a queue before submission for rendering. Latency is often used to control how the CPU chooses between responding to user input and frames that are in the render queue. It is often beneficial for applications that have no user input (for example, video playback) to queue more than 3 frames of data.

This method is not supported by DXGI 1.0, which shipped in Windows?Vista and Windows Server?2008. DXGI 1.1 support is required, which is available on Windows?7, Windows Server?2008?R2, and as an update to Windows?Vista with Service Pack?2 (SP2) (KB 971644) and Windows Server?2008 (KB 971512).

Frame latency is the number of frames that are allowed to be stored in a queue before submission for rendering. Latency is often used to control how the CPU chooses between responding to user input and frames that are in the render queue. It is often beneficial for applications that have no user input (for example, video playback) to queue more than 3 frames of data.

EnqueueSetEvent calls the SetEvent function on the event object after all previously submitted rendering commands complete or the device is removed.

After an application calls EnqueueSetEvent, it can immediately call the WaitForSingleObject function to put itself to sleep until rendering commands complete.

You cannot use EnqueueSetEvent to determine work completion that is associated with presentation (); instead, we recommend that you use .

The priority value that the Priority parameter specifies describes how valuable the caller considers the content to be. The operating system uses the priority value to discard resources in order of priority. The operating system discards a resource that is offered with low priority before it discards a resource that is offered with a higher priority.

If you call OfferResources to offer a resource while the resource is bound to the pipeline, the resource is unbound. You cannot call OfferResources on a resource that is mapped. After you offer a resource, the resource cannot be mapped or bound to the pipeline until you call the IDXGIDevice2::ReclaimResource method to reclaim the resource. You cannot call OfferResources to offer immutable resources.

To offer shared resources, call OfferResources on only one of the sharing devices. To ensure exclusive access to the resources, you must use an object and then call OfferResources only while you hold the mutex.

The priority value that the Priority parameter specifies describes how valuable the caller considers the content to be. The operating system uses the priority value to discard resources in order of priority. The operating system discards a resource that is offered with low priority before it discards a resource that is offered with a higher priority.

If you call OfferResources to offer a resource while the resource is bound to the pipeline, the resource is unbound. You cannot call OfferResources on a resource that is mapped. After you offer a resource, the resource cannot be mapped or bound to the pipeline until you call the IDXGIDevice2::ReclaimResource method to reclaim the resource. You cannot call OfferResources to offer immutable resources.

To offer shared resources, call OfferResources on only one of the sharing devices. To ensure exclusive access to the resources, you must use an object and then call OfferResources only while you hold the mutex.

After you call to offer one or more resources, you must call ReclaimResources before you can use those resources again. You must check the values in the array at pDiscarded to determine whether each resource?s content was discarded. If a resource?s content was discarded while it was offered, its current content is undefined. Therefore, you must overwrite the resource?s content before you use the resource.

To reclaim shared resources, call ReclaimResources only on one of the sharing devices. To ensure exclusive access to the resources, you must use an object and then call ReclaimResources only while you hold the mutex.

After you call to offer one or more resources, you must call ReclaimResources before you can use those resources again. You must check the values in the array at pDiscarded to determine whether each resource?s content was discarded. If a resource?s content was discarded while it was offered, its current content is undefined. Therefore, you must overwrite the resource?s content before you use the resource.

To reclaim shared resources, call ReclaimResources only on one of the sharing devices. To ensure exclusive access to the resources, you must use an object and then call ReclaimResources only while you hold the mutex.

EnqueueSetEvent calls the SetEvent function on the event object after all previously submitted rendering commands complete or the device is removed.

After an application calls EnqueueSetEvent, it can immediately call the WaitForSingleObject function to put itself to sleep until rendering commands complete.

You cannot use EnqueueSetEvent to determine work completion that is associated with presentation (); instead, we recommend that you use .

Note??Use this method in Metro style apps rather than .

If you specify the width, height, or both (Width and Height members of that pDesc points to) of the swap chain as zero, the runtime obtains the size from the output window that the pWindow parameter specifies. You can subsequently call the method to retrieve the assigned width or height value.

Because you can associate only one flip presentation model swap chain at a time with an IWindow, the Microsoft Direct3D?11 policy of deferring the destruction of objects can cause problems if you attempt to destroy a flip presentation model swap chain and replace it with another swap chain. For more info about this situation, see Deferred Destruction Issues with Flip Presentation Swap Chains.

We recommend that windowed applications call IsWindowedStereoEnabled before they attempt to use stereo. IsWindowedStereoEnabled returns TRUE if both of the following items are true:

• All adapters in the computer have drivers that are capable of stereo. This only means that the driver is implemented to the Windows Display Driver Model (WDDM) for Windows?8 Consumer Preview (WDDM 1.2). However, the adapter does not necessarily have to be able to scan out stereo.
• The current desktop mode (desktop modes are mono) and system policy and hardware are configured so that the Desktop Window Manager (DWM) performs stereo composition on at least one adapter output.

The creation of a windowed stereo swap chain succeeds if the first requirement is met. However, if the adapter can't scan out stereo, the output on that adapter is reduced to mono.

The Direct3D 11.1 Simple Stereo 3D Sample shows how to add a stereoscopic 3D effect and how to respond to system stereo changes.

Note??Do not use this method in Metro style apps. Instead, use .

If you specify the width, height, or both (Width and Height members of that pDesc points to) of the swap chain as zero, the runtime obtains the size from the output window that the hWnd parameter specifies. You can subsequently call the method to retrieve the assigned width or height value.

Because you can associate only one flip presentation model swap chain at a time with an , the Microsoft Direct3D?11 policy of deferring the destruction of objects can cause problems if you attempt to destroy a flip presentation model swap chain and replace it with another swap chain. For more info about this situation, see Deferred Destruction Issues with Flip Presentation Swap Chains.

Note??Use this method in Metro style apps rather than .

If you specify the width, height, or both (Width and Height members of that pDesc points to) of the swap chain as zero, the runtime obtains the size from the output window that the pWindow parameter specifies. You can subsequently call the method to retrieve the assigned width or height value.

Because you can associate only one flip presentation model swap chain at a time with an IWindow, the Microsoft Direct3D?11 policy of deferring the destruction of objects can cause problems if you attempt to destroy a flip presentation model swap chain and replace it with another swap chain. For more info about this situation, see Deferred Destruction Issues with Flip Presentation Swap Chains.

You cannot share resources across adapters. Therefore, you cannot open a shared resource on an adapter other than the adapter on which the resource was created. Call GetSharedResourceAdapterLuid before you open a shared resource to ensure that the resource was created on the appropriate adapter. To open a shared resource, call the or method.

Apps choose the Windows message that Windows sends when occlusion status changes.

If you call RegisterOcclusionStatusEvent multiple times with the same event handle, RegisterOcclusionStatusEvent fails with .

If you call RegisterOcclusionStatusEvent multiple times with the different event handles, RegisterOcclusionStatusEvent properly registers the events.

You can use composition swap chains with either DirectComposition?s IDCompositionVisual interface or XAML?s SwapChainBackgroundPanel class. For DirectComposition, you can call the IDCompositionVisual::SetContent method to set the swap chain as the content of a visual object, which then allows you to bind the swap chain to the visual tree. For XAML, the SwapChainBackgroundPanel class exposes a classic COM interface . You can use the method to bind to the XAML UI graph.

The , , , , and IDXGISwapChain::GetCoreWindow methods aren't valid on this type of swap chain. If you call any of these methods on this type of swap chain, they fail.

We recommend that windowed applications call IsWindowedStereoEnabled before they attempt to use stereo. IsWindowedStereoEnabled returns TRUE if both of the following items are true:

• All adapters in the computer have drivers that are capable of stereo. This only means that the driver is implemented to the Windows Display Driver Model (WDDM) for Windows?8 Consumer Preview (WDDM 1.2). However, the adapter does not necessarily have to be able to scan out stereo.
• The current desktop mode (desktop modes are mono) and system policy and hardware are configured so that the Desktop Window Manager (DWM) performs stereo composition on at least one adapter output.

The creation of a windowed stereo swap chain succeeds if the first requirement is met. However, if the adapter can't scan out stereo, the output on that adapter is reduced to mono.

The Direct3D 11.1 Simple Stereo 3D Sample shows how to add a stereoscopic 3D effect and how to respond to system stereo changes.

This interface provides the native implementation of the Windows::UI::XAML::Control::SwapChainBackgroundPanel Windows Runtime type. To obtain a reference to , you must cast a SwapChainBackgroundPanel instance to IInspectable or , and call QueryInterface.

 Microsoft::WRL::ComPtr<>	m_swapChainNative;	
            // ...	
            IInspectable* panelInspectable = (IInspectable*) reinterpret_cast<IInspectable*>(swapChainPanel);	
            panelInspectable->QueryInterface(__uuidof(), (void **)&m_swapChainNative); 

This interface is implemented by the developer to provide specific drawing behaviors for updates to a VirtualSurfaceImageSource. Classes that implement this interface are provided to the , which calls the UpdatesNeeded method implementation whenever an update is requested.

This method is implemented by the developer.

The AcquireSync method creates a lock to a surface that is shared between multiple devices, allowing only one device to render to a surface at a time. This method uses a key to determine which device currently has exclusive access to the surface.

When a surface is created using the D3D10_RESOURCE_MISC_SHARED_KEYEDMUTEX value of the D3D10_RESOURCE_MISC_FLAG enumeration, you must call the AcquireSync method before rendering to the surface. You must call the ReleaseSync method when you are done rendering to a surface.

To acquire a reference to the keyed mutex object of a shared resource, call the QueryInterface method of the resource and pass in the UUID of the interface. For more information about acquiring this reference, see the following code example.

The AcquireSync method uses the key as follows, depending on the state of the surface:

• On initial creation, the surface is unowned and any device can call the AcquireSync method to gain access. For an unowned device, only a key of 0 will succeed. Calling the AcquireSync method for any other key will stall the calling CPU thread.
• If the surface is owned by a device when you call the AcquireSync method, the CPU thread that called the AcquireSync method will stall until the owning device calls the ReleaseSync method using the same Key.
• If the surface is unowned when you call the AcquireSync method (for example, the last owning device has already called the ReleaseSync method), the AcquireSync method will succeed if you specify the same key that was specified when the ReleaseSync method was last called. Calling the AcquireSync method using any other key will cause a stall.
• When the owning device calls the ReleaseSync method with a particular key, and more than one device is waiting after calling the AcquireSync method using the same key, any one of the waiting devices could be woken up first. The order in which devices are woken up is undefined.
• A keyed mutex does not support recursive calls to the AcquireSync method.

The AcquireSync method creates a lock to a surface that is shared between multiple devices, allowing only one device to render to a surface at a time. This method uses a key to determine which device currently has exclusive access to the surface.

When a surface is created using the D3D10_RESOURCE_MISC_SHARED_KEYEDMUTEX value of the D3D10_RESOURCE_MISC_FLAG enumeration, you must call the AcquireSync method before rendering to the surface. You must call the ReleaseSync method when you are done rendering to a surface.

To acquire a reference to the keyed mutex object of a shared resource, call the QueryInterface method of the resource and pass in the UUID of the interface. For more information about acquiring this reference, see the following code example.

The AcquireSync method uses the key as follows, depending on the state of the surface:

• On initial creation, the surface is unowned and any device can call the AcquireSync method to gain access. For an unowned device, only a key of 0 will succeed. Calling the AcquireSync method for any other key will stall the calling CPU thread.
• If the surface is owned by a device when you call the AcquireSync method, the CPU thread that called the AcquireSync method will stall until the owning device calls the ReleaseSync method using the same Key.
• If the surface is unowned when you call the AcquireSync method (for example, the last owning device has already called the ReleaseSync method), the AcquireSync method will succeed if you specify the same key that was specified when the ReleaseSync method was last called. Calling the AcquireSync method using any other key will cause a stall.
• When the owning device calls the ReleaseSync method with a particular key, and more than one device is waiting after calling the AcquireSync method using the same key, any one of the waiting devices could be woken up first. The order in which devices are woken up is undefined.
• A keyed mutex does not support recursive calls to the AcquireSync method.

The ReleaseSync method releases a lock to a surface that is shared between multiple devices. This method uses a key to determine which device currently has exclusive access to the surface.

When a surface is created using the D3D10_RESOURCE_MISC_SHARED_KEYEDMUTEX value of the D3D10_RESOURCE_MISC_FLAG enumeration, you must call the method before rendering to the surface. You must call the ReleaseSync method when you are done rendering to a surface.

After you call the ReleaseSync method, the shared resource is unset from the rendering pipeline.

To acquire a reference to the keyed mutex object of a shared resource, call the QueryInterface method of the resource and pass in the UUID of the interface. For more information about acquiring this reference, see the following code example.

To see the outputs available, use . To see the specific output that the swap chain will update, use .

In general, when switching from windowed to full-screen mode, a swap chain automatically chooses a display mode that meets (or exceeds) the resolution, color depth and refresh rate of the swap chain. To exercise more control over the display mode, use this API to poll the set of display modes that are validated against monitor capabilities, or all modes that match the desktop (if the desktop settings are not validated against the monitor).

As shown, this API is designed to be called twice. First to get the number of modes available, and second to return a description of the modes.

 UINT num = 0;	
             format = ;	
            UINT flags         = ; pOutput->GetDisplayModeList( format, flags, &num, 0); ...  * pDescs = new [num];	
            pOutput->GetDisplayModeList( format, flags, &num, pDescs); 

FindClosestMatchingMode behaves similarly to the except FindClosestMatchingMode considers only the mono display modes. considers only stereo modes if you set the Stereo member in the structure that pModeToMatch points to, and considers only mono modes if Stereo is not set.

returns a matched display-mode set with only stereo modes or only mono modes. FindClosestMatchingMode behaves as though you specified the input mode as mono.

A vertical blank occurs when the raster moves from the lower right corner to the upper left corner to begin drawing the next frame.

When you are finished with the output, call .

TakeOwnership should not be called directly by applications, since results will be unpredictable. It is called implicitly by the DXGI swap chain object during full-screen transitions, and should not be used as a substitute for swap-chain methods.

If a Metro style app uses TakeOwnership, it fails with .

If you are not using a swap chain, get access to an output by calling and release it when you are finished by calling . An application that uses a swap chain will typically not call either of these methods.

Note??Calling this method is only supported while in full-screen mode.

Note??Calling this method is only supported while in full-screen mode.

Note??Calling this method is only supported while in full-screen mode.

should not be called directly by applications, since results will be unpredictable. It is called implicitly by the DXGI swap chain object during full-screen transitions, and should not be used as a substitute for swap-chain methods.

This method should only be called between and calls.

If a Metro style app uses SetDisplaySurface, it fails with .

can only be called when an output is in full-screen mode. If the method succeeds, DXGI fills the destination surface.

Use to determine the size (width and height) of the output when you want to allocate space for the destination surface. This is true regardless of target monitor rotation. A destination surface created by a graphics component (such as Direct3D 10) must be created with CPU-write permission (see D3D10_CPU_ACCESS_WRITE). Other surfaces should be created with CPU read-write permission (see D3D10_CPU_ACCESS_READ_WRITE). This method will modify the surface data to fit the destination surface (stretch, shrink, convert format, rotate). The stretch and shrink is performed with point-sampling.

This API is similar to .

Note??Calling this method is only supported while in full-screen mode.

Note??Calling this method is only supported while in full-screen mode.

Note??Calling this method is only supported while in full-screen mode.

This API is similar to .

Note??Calling this method is only supported while in full-screen mode.

If an application wants to duplicate the entire desktop, it must create a desktop duplication interface on each active output on the desktop. This interface does not provide an explicit way to synchronize the timing of each output image. Instead, the application must use the time stamp of each output, and then determine how to combine the images.

For DuplicateOutput to succeed, you must create pDevice from or a later version of a DXGI factory interface that inherits from .

If the current mode is a stereo mode, the desktop duplication interface provides the image for the left stereo image only.

By default, only four processes can use a IDXGIOutputDuplication interface at the same time within a single session. A process can have only one desktop duplication interface on a single desktop output; however, that process can have a desktop duplication interface for each output that is part of the desktop.

If DuplicateOutput fails with , the application can wait for system notification of desktop switches and mode changes and then call DuplicateOutput again after such a notification occurs. For more information, see information in desktop switch (EVENT_SYSTEM_DESKTOPSWITCH) and mode change notification (WM_DISPLAYCHANGE).

GetDisplayModeList1 is updated from GetDisplayModeList to return a list of structures, which are updated mode descriptions. GetDisplayModeList behaves as though it calls GetDisplayModeList1 because GetDisplayModeList can return all of the modes that are specified by DXGI_ENUM_MODES, including stereo mode. However, GetDisplayModeList returns a list of structures, which are the former mode descriptions and do not indicate stereo mode.

The GetDisplayModeList1 method does not enumerate stereo modes unless you specify the flag in the Flags parameter. If you specify , stereo modes are included in the list of returned modes that the pDesc parameter points to. In other words, the method returns both stereo and mono modes.

In general, when you switch from windowed to full-screen mode, a swap chain automatically chooses a display mode that meets (or exceeds) the resolution, color depth, and refresh rate of the swap chain. To exercise more control over the display mode, use GetDisplayModeList1 to poll the set of display modes that are validated against monitor capabilities, or all modes that match the desktop (if the desktop settings are not validated against the monitor).

The following example code shows that you need to call GetDisplayModeList1 twice. First call GetDisplayModeList1 to get the number of modes available, and second call GetDisplayModeList1 to return a description of the modes.

 UINT num = 0;	
             format = ;	
            UINT flags         = ; pOutput->GetDisplayModeList1( format, flags, &num, 0); ...  * pDescs = new [num];	
            pOutput->GetDisplayModeList1( format, flags, &num, pDescs); 

Direct3D devices require UNORM formats.

FindClosestMatchingMode1 finds the closest matching available display mode to the mode that you specify in pModeToMatch.

If you set the Stereo member in the structure to which pModeToMatch points to specify a stereo mode as input, FindClosestMatchingMode1 considers only stereo modes. FindClosestMatchingMode1 considers only mono modes if Stereo is not set.

FindClosestMatchingMode1 resolves similarly ranked members of display modes (that is, all specified, or all unspecified, and so on) in the following order:

1. ScanlineOrdering
2. Scaling
3. Format
4. Resolution
5. RefreshRate

When FindClosestMatchingMode1 determines the closest value for a particular member, it uses previously matched members to filter the display mode list choices, and ignores other members. For example, when FindClosestMatchingMode1 matches Resolution, it already filtered the display mode list by a certain ScanlineOrdering, Scaling, and Format, while it ignores RefreshRate. This ordering doesn't define the absolute ordering for every usage scenario of FindClosestMatchingMode1, because the application can choose some values initially, which effectively changes the order of resolving members.

FindClosestMatchingMode1 matches members of the display mode one at a time, generally in a specified order.

If a member is unspecified, FindClosestMatchingMode1 gravitates toward the values for the desktop related to this output. If this output is not part of the desktop, FindClosestMatchingMode1 uses the default desktop output to find values. If an application uses a fully unspecified display mode, FindClosestMatchingMode1 typically returns a display mode that matches the desktop settings for this output. Because unspecified members are lower priority than specified members, FindClosestMatchingMode1 resolves unspecified members later than specified members.

GetDisplaySurfaceData1 is similar to except GetDisplaySurfaceData1 takes an and takes an .

GetDisplaySurfaceData1 returns an error if the input resource is not a 2D texture (represented by the interface) with an array size (ArraySize member of the structure) that is equal to the swap chain buffers.

The original and the updated GetDisplaySurfaceData1 behave exactly the same. GetDisplaySurfaceData1 was required because textures with an array size equal to 2 (ArraySize = 2) do not implement .

You can call GetDisplaySurfaceData1 only when an output is in full-screen mode. If GetDisplaySurfaceData1 succeeds, it fills the destination resource.

Use to determine the size (width and height) of the output when you want to allocate space for the destination resource. This is true regardless of target monitor rotation. A destination resource created by a graphics component (such as Direct3D 11) must be created with CPU write permission (see ). Other surfaces can be created with CPU read-write permission ( | ). GetDisplaySurfaceData1 modifies the surface data to fit the destination resource (stretch, shrink, convert format, rotate). GetDisplaySurfaceData1 performs the stretch and shrink with point sampling.

If an application wants to duplicate the entire desktop, it must create a desktop duplication interface on each active output on the desktop. This interface does not provide an explicit way to synchronize the timing of each output image. Instead, the application must use the time stamp of each output, and then determine how to combine the images.

For DuplicateOutput to succeed, you must create pDevice from or a later version of a DXGI factory interface that inherits from .

If the current mode is a stereo mode, the desktop duplication interface provides the image for the left stereo image only.

By default, only four processes can use a IDXGIOutputDuplication interface at the same time within a single session. A process can have only one desktop duplication interface on a single desktop output; however, that process can have a desktop duplication interface for each output that is part of the desktop.

If DuplicateOutput fails with , the application can wait for system notification of desktop switches and mode changes and then call DuplicateOutput again after such a notification occurs. For more information, see information in desktop switch (EVENT_SYSTEM_DESKTOPSWITCH) and mode change notification (WM_DISPLAYCHANGE).

You can create a swap chain in several ways. If your application uses Direct3D, create a swap chain when you create a device by calling D3D10CreateDeviceAndSwapChain or D3D11CreateDeviceAndSwapChain. If your application does not need Direct3D, create a swap chain for use directly with DXGI by calling , , IDXGIFactory2::CreateSwapChainForImmersiveWindow, or IDXGIFactory2::CreateSwapChainForCompositionSurface.

For the best performance when flipping swap-chain buffers in a full-screen application, see Full-Screen Application Performance Hints.

Because calling Present might cause the render thread to wait on the message-pump thread, be careful when calling this method in an application that uses multiple threads. For more details, see Multithreading Considerations.

?

For flip presentation model swap chains that you create with the value set, a successful presentation unbinds back buffer 0 from the graphics pipeline, except for when you pass the flag in the Flags parameter.

Suppose the following frames with sync-interval values are queued from oldest (A) to newest (E) before you call Present.

A: 3, B: 0, C: 0, D: 1, E: 0

When you call Present, the runtime shows frame A for 3 vertical blank intervals, then frame D for 1 vertical blank interval, and then frame E until you submit a new presentation. The runtime discards frames C and D.

DXGI may change the display state of a swap chain in response to end user or system requests.

We recommend that you create a windowed swap chain and allow the end user to change the swap chain to full screen through SetFullscreenState; that is, do not set the Windowed member of to to force the swap chain to be full screen. However, if you create the swap chain as full screen, also provide the end user with a list of supported display modes because a swap chain that is created with an unsupported display mode might cause the display to go black and prevent the end user from seeing anything. Also, we recommend that you have a time-out confirmation screen or other fallback mechanism when you allow the end user to change display modes.

If a Metro style app calls SetFullscreenState to set the display state to full screen, SetFullscreenState fails with .

You cannot call SetFullscreenState on a windowless swap chain that you created with IDXGIFactory2::CreateSwapChainForCompositionSurface.

For the flip presentation model, after you transition the display state to full screen, you must call ResizeBuffers to ensure that your call to succeeds.

When the swap chain is in full-screen mode, a reference to the target output will be returned and its reference count will be incremented.

You can't resize a swap chain unless you release all outstanding references to its back buffers. You must release all of its direct and indirect references on the back buffers in order for ResizeBuffers to succeed.

Direct references are held by the application after it calls AddRef on a resource.

Indirect references are held by views to a resource, binding a view of the resource to a device context, a command list that used the resource, a command list that used a view to that resource, a command list that executed another command list that used the resource, and so on.

Before you call ResizeBuffers, ensure that the application releases all references (by calling the appropriate number of Release invocations) on the resources, any views to the resource, and any command lists that use either the resources or views, and ensure that neither the resource nor a view is still bound to a device context. You can use to ensure that all references are released. If a view is bound to a deferred context, you must discard the partially built command list as well (by calling ClearState, , then Release on the command list). After you call ResizeBuffers, you can re-query interfaces via .

For swap chains that you created with , before you call ResizeBuffers, also call on the swap chain's back-buffer surface to ensure that you have no outstanding GDI device contexts (DCs) open.

We recommend that you call ResizeBuffers when a client window is resized (that is, when an application receives a WM_SIZE message).

The only difference between ResizeBuffers in Windows Developer Preview and ResizeBuffers in Windows?7 is with flip presentation model swap chains that you create with the value set. In Windows Developer Preview, you must call ResizeBuffers to realize a transition between full-screen mode and windowed mode; otherwise, your next call to the Present method fails.

ResizeTarget resizes the target window when the swap chain is in windowed mode, and changes the display mode on the target output when the swap chain is in full-screen mode. Therefore, applications can call ResizeTarget to resize the target window (rather than a Microsoft Win32API such as SetWindowPos) without knowledge of the swap chain display mode.

If a Metro style app calls ResizeTarget, it fails with .

You cannot call ResizeTarget on a windowless swap chain that you created with IDXGIFactory2::CreateSwapChainForCompositionSurface.

If the method succeeds, the output interface will be filled and its reference count incremented. When you are finished with it, be sure to release the interface to avoid a memory leak.

The output is also owned by the adapter on which the swap chain's device was created.

You cannot call GetContainingOutput on a windowless swap chain that you created with IDXGIFactory2::CreateSwapChainForCompositionSurface.

You cannot use GetFrameStatistics for swap chains that both use the bit-block transfer (bitblt) presentation model and draw in windowed mode.

You can only use GetFrameStatistics for swap chains that either use the flip presentation model or draw in full-screen mode. You set the value in the SwapEffect member of the structure to specify that the swap chain uses the flip presentation model.

For info about presentation statistics for a frame, see .

If the method succeeds, the output interface will be filled and its reference count incremented. When you are finished with it, be sure to release the interface to avoid a memory leak.

The output is also owned by the adapter on which the swap chain's device was created.

You cannot call GetContainingOutput on a windowless swap chain that you created with IDXGIFactory2::CreateSwapChainForCompositionSurface.

You cannot use GetFrameStatistics for swap chains that both use the bit-block transfer (bitblt) presentation model and draw in windowed mode.

You can only use GetFrameStatistics for swap chains that either use the flip presentation model or draw in full-screen mode. You set the value in the SwapEffect member of the structure to specify that the swap chain uses the flip presentation model.

For info about presentation statistics for a frame, see .

You can create a swap chain by calling , , or . You can also create a swap chain when you call D3D11CreateDeviceAndSwapChain; however, you can then only access the sub-set of swap-chain functionality that the interface provides.

provides the IsTemporaryMonoSupported method that you can use to determine whether the swap chain supports "temporary mono? presentation. This type of swap chain is a stereo swap chain that can be used to present mono content.

Note??Some stereo features like the advanced presentation flags are not represented by an explicit interface change. Furthermore, the original () and new () swap chain interfaces generally have the same behavior. For information about how methods are translated into methods, see the descriptions of the methods.

The semantics of GetFullscreenDesc are identical to that of the IDXGISwapchain::GetDesc method for -based swap chains.

Applications call the method to create a swap chain that is associated with an .

Applications call the method to create a swap chain that is associated with an IWindow object.

An application can use Present1 to optimize presentation by specifying scroll and dirty rectangles. When the runtime has information about these rectangles, the runtime can then perform necessary bitblts during presentation more efficiently and pass this metadata to the Desktop Window Manager (DWM). The DWM can then use the metadata to optimize presentation and pass the metadata to indirect displays and terminal servers to optimize traffic over the wire. An application must confine its modifications to only the dirty regions that it passes to Present1, as well as modify the entire dirty region to avoid undefined resource contents from being exposed.

For flip presentation model swap chains that you create with the value set, a successful presentation results in an unbind of back buffer 0 from the graphics pipeline, except for when you pass the flag in the Flags parameter.

Suppose the following frames with sync-interval values are queued from oldest (A) to newest (E) before you call Present1.

A: 3, B: 0, C: 0, D: 1, E: 0

When you call Present1, the runtime shows frame A for 3 vertical blank intervals, then frame D for 1 vertical blank interval, and then frame E until you submit a new presentation. The runtime discards frames B and C.

Temporary mono is a feature where a stereo swap chain can be presented using only the content in the left buffer. To present using the left buffer as a mono buffer, an application calls the method with the flag. All windowed swap chains support temporary mono. However, full-screen swap chains optionally support temporary mono because not all hardware supports temporary mono on full-screen swap chains efficiently.

If the method succeeds, the runtime fills the buffer at ppRestrictToOutput with a reference to the restrict-to output interface. This restrict-to output interface has its reference count incremented. When you are finished with it, be sure to release the interface to avoid a memory leak.

The output is also owned by the adapter on which the swap chain's device was created.

The background color affects only swap chains that you create with in windowed mode. You pass this value in a call to , , or . Typically, the background color is not visible unless the swap-chain contents are smaller than the destination window.

When you set the background color, it is not immediately realized. It takes effect in conjunction with your next call to the method. The DXGI_PRESENT flags that you pass to can help achieve the effect that you require. For example, if you call SetBackgroundColor and then call with the Flags parameter set to , you change only the background color without changing the displayed contents of the swap chain.

When you call the method to display contents of the swap chain, uses the value that is specified in the AlphaMode member of the structure to determine how to handle the a member of the DXGI_RGBA structure, the alpha value of the background color, that achieves window transparency. For example, if AlphaMode is , ignores the a member of DXGI_RGBA.

Note??The background color that GetBackgroundColor retrieves does not indicate what the screen currently displays. The background color indicates what the screen will display with your next call to the method. The default value of the background color is black with full opacity: 0,0,0,1.

You can only use SetRotation to rotate the back buffers for flip-model swap chains that you present in windowed mode.

SetRotation isn't supported for rotating the back buffers for flip-model swap chains that you present in full-screen mode. In this situation, SetRotation doesn't fail, but you must ensure that you specify no rotation () for the swap chain. Otherwise, when you call or to present a frame, the presentation fails.

The semantics of GetFullscreenDesc are identical to that of the IDXGISwapchain::GetDesc method for -based swap chains.

Applications call the method to create a swap chain that is associated with an .

Temporary mono is a feature where a stereo swap chain can be presented using only the content in the left buffer. To present using the left buffer as a mono buffer, an application calls the method with the flag. All windowed swap chains support temporary mono. However, full-screen swap chains optionally support temporary mono because not all hardware supports temporary mono on full-screen swap chains efficiently.

If the method succeeds, the runtime fills the buffer at ppRestrictToOutput with a reference to the restrict-to output interface. This restrict-to output interface has its reference count incremented. When you are finished with it, be sure to release the interface to avoid a memory leak.

The output is also owned by the adapter on which the swap chain's device was created.

Note??The background color that GetBackgroundColor retrieves does not indicate what the screen currently displays. The background color indicates what the screen will display with your next call to the method. The default value of the background color is black with full opacity: 0,0,0,1.

The structure provides a DXGI 1.2 description of an adapter. This structure is initialized by using the method.

The structure provides a description of an adapter. This structure is initialized by using the method.

The structure provides a DXGI 1.1 description of an adapter. This structure is initialized by using the method.

You initialize the structure with the or method.

You can only use for swap chains that either use the flip presentation model or draw in full-screen mode. You set the value in the SwapEffect member of the structure to specify that the swap chain uses the flip presentation model.

The values in the PresentCount and PresentRefreshCount members indicate information about when a frame was presented on the display screen. You can use these values to determine whether a glitch occurred. The values in the SyncRefreshCount and SyncQPCTime members indicate timing information that you can use for audio and video synchronization or very precise animation. If the swap chain draws in full-screen mode, these values are based on when the computer booted. If the swap chain draws in windowed mode, these values are based on when the swap chain is created.

The structure is used by the method.

To get a list of the capabilities for controlling gamma correction, call .

The structure is initialized by the method.

The following format values are valid for display modes and when you create a bit-block transfer (bitblt) model swap chain. The valid values depend on the feature level that you are working with.

• Feature level >= 9.1

  • (except 10.x on Windows?Vista)
  • (except 10.x on Windows?Vista)

• Feature level >= 10.0

• Feature level >= 11.0

You can pass one of these format values to to determine if it is a valid format for displaying on screen. If returns in the bit field to which the pFormatSupport parameter points, the format is valid for displaying on screen.

Starting with Windows Developer Preview for a flip model swap chain (that is, a swap chain that has the value set in the SwapEffect member of ), you must set the Format member of to , , or .

Because of the relaxed render target creation rules that Direct3D 11 has for back buffers, applications can create a render target view from a swap chain so they can use automatic color space conversion when they render the swap chain.

is identical to except that includes the Stereo member.

The structure is initialized by the method.

The scroll rectangle and the list of dirty rectangles could overlap. In this situation, the dirty rectangles take priority. Applications can then have pieces of dynamic content on top of a scrolled area. For example, an application could scroll a page and play video at the same time.

The following diagram and coordinates illustrate this example.

Parts of the previous frame and content that the application renders are combined to produce the final frame that the operating system presents on the display screen. Most of the window is scrolled from the previous frame. The application must update the video frame with the new chunk of content that appears due to scrolling.

The dashed rectangle shows the scroll rectangle in the current frame. The scroll rectangle is specified by the pScrollRect member. The arrow shows the scroll offset. The scroll offset is specified by the pScrollOffset member. Filled rectangles show dirty rectangles that the application updated with new content. The filled rectangles are specified by the DirtyRectsCount and pDirtyRects members.

The scroll rectangle and offset are not supported for the or present option. Dirty rectangles and scroll rectangle are not supported for multisampled swap chains.

The actual implementation of composition and necessary bitblts is different for the bitblt model and the flip model.

The structure operates under the following rules:

• 0/0 is legal and will be interpreted as 0/1.
• 0/anything is interpreted as zero.
• If you are representing a whole number, the denominator should be 1.