Managing Device Resources
[This documentation is for preview only, and is subject to change in later releases. Blank topics are included as placeholders.]
There are two basic types of resources in managed mobile Direct3D programming: those that need to be re-created when a device is reset and those that do not. Various object types may or may not be filled with data when a device resets. Unlike Direct3D in desktop computer applications, the memory pool used for the creation of a resource is not a factor in whether a resource must be re-created when a device is reset.
Memory Pooling
There are three memory pools available in managed mobile Direct3D programming:
System
Allocates in normal system memory on the mobile device, which is typically slower to use than video memory.
Video
Allocates a memory area that is primarily for use by video hardware on the mobile device. On some devices, video memory may be a highly constrained resource.
Managed memory
Allocates video memory as a cache of system memory. The driver may use several algorithms, including the LRU (least recently used) replacement algorithm, to implement the caching scheme.
When a texture or other resource is created in the managed pool, space is allocated in the system memory pool for the texture. When the texture is assigned to a texture stage with the SetTexture method, the texture is uploaded into the video memory pool and held until it becomes the least-used item and is eventually evicted to make room for another resource. When room needs to be made in video memory to upload a managed surface, and no item meets the LRU definition, the driver should use the Priority property to determine what managed memory resource to evict from video memory.
You can create VertexBuffer, IndexBuffer, and Texture resources in the managed pool, but not front and back buffers, depth buffers, and image surfaces.
You can use an instance of the SurfaceCaps structure to determine which memory pools are accessible when you create a resource.
A mobile device can support different memory pools for different types of resources. Display drivers indicate their support for the managed resource pool with the SupportsManagedPool property of a SurfaceCaps. If this property is true, the device supports the managed pool for VertexBuffer, IndexBuffer, and Texture resources. An application cannot create a surface from the managed pool if the driver does not support the managed pool. If the device supports both the system and video memory pools for textures, the application may implement its own memory caching scheme by using the UpdateTexture method.
The application can also force a surface to be preloaded into video memory with the PreLoad method of a Resource. This method causes the necessary bytes to be discarded and the surface to be loaded immediately.
Finally, the application may also force the resource managed to discard a given number of bytes with the ResourceManagerDiscardBytes method of a Device. This method takes the number of bytes to discard as an argument. If the application passes 0, all managed bytes in video memory are discarded.
All methods that control the resource manager act immediately; they are not buffered in the command buffer. Also, they fail if the device does not support the managed pool.
Object Instances and Lifetimes
When managing device resets and using index buffers or vertex buffers, you must use the appropriate constructors so that objects are created with the appropriate lifetimes.
Windows Mobile Direct3D supports only one Device instance at a time on a Smartphone or Pocket PC. You can use the ReleaseD3DMobile static method of a Manager to remove all Direct3D device resources so you can start another Windows Mobile Direct3D application on the same Pocket PC or Smartphone.
The following objects must be re-created when a Device is reset. The re-creation can be performed in an event handler for the DeviceReset event.
Texture objects.
Mesh objects.
Surface objects.
VertexBuffer objects that were created with the VertexBuffer(Device, Int32, Usage, VertexFormats, Pool) constructor.
IndexBuffer objects that were created with the IndexBuffer(Device, Int32, Usage, Pool, Boolean) constructor.
The following objects do not need to be re-created when a Device is reset:
Font objects.
Sprite objects.
VertexBuffer objects created with the VertexBuffer(Type, Int32, Device, Usage, VertexFormats, Pool) constructor.
IndexBuffer objects created with the IndexBuffer(Type, Int32, Device, Usage, Pool) constructor.
Font and Sprite objects automatically perform all necessary actions in response to device reset.
The IndexBuffer and VertexBuffer objects re-create themselves automatically when a device is reset, but they will not have data within them. You can define an event handler for the IndexBuffer.Created event or VertexBuffer.Created event to fill the index or vertex buffer with data after the device is reset.