Performance Considerations for Direct3D9 and WPF Interoperability

Direct3D9 content hosted in a D3DImage instance does not render as fast as in a pure Direct3D application. Copying the surface and flushing the command buffer can be costly operations. As the number of D3DImage instances increases, more flushing occurs, and performance degrades. Therefore, you should use D3DImage sparingly.

For best performance on Windows Vista with a display that is configured to use the Windows Display Driver Model (WDDM), create your Direct3D9 surface on an IDirect3DDevice9Exdevice. This enables surface sharing. The video card must support the D3DDEVCAPS2_CAN_STRETCHRECT_FROM_TEXTURES and D3DCAPS2_CANSHARERESOURCE driver capabilities on Windows Vista. Any other settings cause the surface to be copied through software, which reduces performance significantly.

Note
If Windows Vista has a display that is configured to use the Windows XP Display Driver Model (XDDM), the surface is always copied through software, regardless of settings. With the proper settings and video card, you will see better performance on Windows Vista when you use the WDDM because surface copies are performed in hardware.

For best performance on Windows XP, which uses the Windows XP Display Driver Model (XDDM), create a lockable surface that behaves correctly when the IDirect3DSurface9::GetDCmethod is called. Internally, the BitBlt method transfers the surface across devices in hardware. The GetDC method always works on XRGB surfaces. However, if the client computer is running Windows XP with SP3 or SP2, and if the client also has the hotfix for the layered-window feature, this method only works on ARGB surfaces. The video card must support theD3DDEVCAPS2_CAN_STRETCHRECT_FROM_TEXTURES driver capability.

A 16-bit desktop display depth can significantly reduce performance. A 32-bit desktop is recommended.

If you are developing for Windows Vista and Windows XP, test the performance on Windows XP. Running out of video memory on Windows XP is a concern. In addition, D3DImage on Windows XP uses more video memory and bandwidth than Windows Vista WDDM, due to a necessary extra video memory copy. Therefore, you can expect performance to be worse on Windows XP than on Windows Vista for the same video hardware.

Note
XDDM is available on both Windows XP and Windows Vista; however, WDDM is available only on Windows Vista.

When you create the device, use the D3DCREATE_MULTITHREADED creation flag. This reduces performance, but the WPF rendering system calls methods on this device from another thread. Be sure to follow the locking protocol correctly, so that no two threads access the device at the same time.

If your rendering is performed on a WPF managed thread, it is strongly recommended that you create the device with the D3DCREATE_FPU_PRESERVE creation flag. Without this setting, the D3D rendering can reduce the accuracy of WPF double-precision operations and introduce rendering issues.

Tiling a D3DImage is fast, unless you tile a non-pow2 surface without hardware support, or if you tile a DrawingBrush or VisualBrush that contains a D3DImage.

If you are using a computer that has multiple monitors, you should follow the previously described best practices. There are also some additional performance considerations for a multi-monitor configuration.

When you create the back buffer, it is created on a specific device and adapter, but WPF may display the front buffer on any adapter. Copying across adapters to update the front buffer can be very expensive. On Windows Vista that is configured to use the WDDM with multiple video cards and with an IDirect3DDevice9Ex device, if the front buffer is on a different adapter but still the same video card, there is no performance penalty. However, on Windows XP and the XDDM with multiple video cards, there is a significant performance penalty when the front buffer is displayed on a different adapter than the back buffer. For more information, see WPF and Direct3D9 Interoperation.

The following table shows performance of the front buffer update as a function of operating system, pixel format, and surface lockability. The front buffer and back buffer are assumed to be on the same adapter. Depending on the adapter configuration, hardware updates are generally much faster than software updates.

Tasks

Reference

Concepts