Lost Devices (Windows Embedded CE 6.0)
1/6/2010
A Microsoft® Direct3D® Mobile device can be in either an operational state or a lost state. The operational state is the normal state of the device; the device executes and presents all rendering as expected. The device makes a transition to the lost state when an event — such as the loss of keyboard focus in a full-screen application — causes rendering to become impossible. The lost state is characterized by the silent failure of all rendering operations, which means that the rendering methods can return success codes even though the rendering operations fail. In this situation, the D3DMERR_DEVICELOST error code (see D3DMERR Values) is returned by IDirect3DMobileDevice::Present.
By design, the full set of scenarios that can cause a device to become lost is not specified. Some typical examples include loss of focus or when a system dialog is initialized. Devices can also be lost due to a power management event, or when another application assumes full-screen operation. In addition, any failure from IDirect3DMobileDevice::Reset puts the device into a lost state.
Responding to a Lost Device
If a device is lost, the application queries the device to see if it can be restored to the operational state. If not, the application waits until the device can be restored.
If the device can be restored, the application prepares the device by destroying all video-memory resources and any swap chains. Then, the application calls the IDirect3DMobileDevice::Reset method. Reset is the only method that has an effect when a device is lost, and is the only method by which an application can change the device from a lost to an operational state. Reset will fail unless the application releases all resources that are allocated in D3DMPOOL_VIDEOMEM (see D3DMPOOL), including those created by the IDirect3DMobileDevice::CreateRenderTarget and IDirect3DMobileDevice::CreateDepthStencilSurface methods.
For the most part, the high-frequency calls of Direct3D Mobile do not return any information about whether the device has been lost. The application can continue to call rendering methods, such as IDirect3DMobileDevice::DrawPrimitive, without receiving notification of a lost device. Internally, these operations are discarded until the device is reset to the operational state.
In all cases, destroying video-memory resources is a prerequisite to calling Reset, even if the device has not been lost.
**The application can determine what to do on encountering a lost device by querying the return value of the IDirect3DMobileDevice::TestCooperativeLevel method.
- If the method returns D3DM_OK, the device is operational.
- If the device is lost but cannot be restored at the current time, the return value is D3DMERR_DEVICELOST. This is the case when a full-screen device loses focus. Applications should respond by pausing until the device can be reset. A D3DMERR_DEVICENOTRESET return code from TestCooperativeLevel indicates this situation.
- If the device is lost and can be restored, the return code from TestCooperativeLevel is D3DMERR_DEVICENOTRESET. Note that the return code from the IDirect3DMobileDevice::Present method is still D3DMERR_DEVICELOST.**
Lost Devices and Locking Operations
Internally, Direct3D Mobile does enough work to ensure that a lock operation will succeed after a device is lost. However, it is not guaranteed that the video-memory resource's data will be accurate during the lock operation. It is guaranteed that no error code will be returned. This allows applications to be written without concern for device loss during a lock operation.
Lost Devices and Resources
Resources can consume video memory. Because a lost device is disconnected from the video memory owned by the adapter, it is not possible to guarantee allocation of video memory when the device is lost. As a result, all resource creation methods are implemented to succeed by returning D3DM_OK, but do in fact allocate only dummy system memory. Because any video-memory resource must be destroyed before the device is resized, there is no issue of over-allocating video memory. These dummy surfaces allow lock and copy operations to appear to function normally until the application calls IDirect3DMobileDevice::Present and discovers that the device has been lost.
All video memory must be released before a device can be reset from a lost state to an operational state. This means that the application should release any swap chains created with IDirect3DMobileDevice::CreateAdditionalSwapChain and any resources placed in the D3DMPOOL_VIDEOMEM memory class. The application need not release resources in the D3DMPOOL_MANAGED or D3DMPOOL_SYSTEMMEM memory classes. Other state data is automatically destroyed by the transition to an operational state.
You are encouraged to develop applications with a single code path to respond to device loss. This code path is likely to be similar, if not identical, to the code path taken to initialize the device at startup.
Lost Devices and Retrieved Data
Direct3D Mobile allows applications to copy generated or previously written images from video-memory resources to nonvolatile system-memory resources. Because the source images of such transfers might be lost at any time, Direct3D Mobile allows such copy operations to fail when the device is lost.
The copy operation IDirect3DMobileDevice::CopyRects can return D3DMERR_DEVICELOST when the source object is in volatile memory (D3DMPOOL_VIDEOMEM) and the destination object is in nonvolatile memory (D3DMPOOL_SYSTEMMEM or D3DMPOOL_MANAGED). Another copy operation, IDirect3DMobileDevice::GetFrontBuffer, can fail due to retrieving data from the primary surface. Note that these cases are the only instance of D3DMERR_DEVICELOST outside of the IDirect3DMobileDevice::Present and IDirect3DMobileDevice::Reset methods. One more instance is in Windows Embedded CE method IDirect3DMobileDevice::TestCooperativeLevel.