Gestion des ressources des périphériques
Mise à jour : novembre 2007
Il existe deux types de base de ressources dans la programmation Direct3D mobile managée : celles qui doivent être recréées lorsqu'un appareil de type Smart Device est réinitialisé et celles qui ne doivent pas l'être. Différents types d'objets peuvent être remplis de données ou pas lorsqu'un appareil est réinitialisé. Contrairement à Direct3D dans les applications d'ordinateur de bureau, le pool de mémoires utilisé pour la création d'une ressource ne détermine pas si une ressource doit être recréée lorsqu'un appareil est réinitialisé.
Pool de mémoires
Il existe trois pools de mémoires disponibles dans la programmation Direct3D mobile managée :
Système
Alloue en mémoire système normale sur l'appareil mobile, ce qui est généralement plus lent à utiliser que la mémoire vidéo.
Vidéo
Alloue une zone de mémoire qui est à l'origine destinée à être utilisée par du matériel vidéo sur l'appareil mobile. Sur certains appareils, la mémoire vidéo peut être soumise à des contraintes de ressources.
Mémoire managée
Alloue la mémoire vidéo comme cache de mémoire système. Le pilote peut utiliser plusieurs algorithmes, y compris l'algorithme de remplacement LRU (dernier récemment utilisé), pour implémenter la méthode de mise en cache.
Lorsqu'une texture ou une autre ressource est créée dans le pool managé, l'espace est alloué dans le pool de mémoires système pour la texture. Lorsque la texture est assignée à une étape de texture avec la méthode SetTexture, la texture est téléchargée dans le pool de mémoires vidéo et conservée jusqu'à ce qu'elle devienne l'élément le moins utilisé et qu'elle soit éventuellement supprimée pour laisser la place à une autre ressource. Lorsque de la place doit être faite dans la mémoire vidéo pour télécharger une surface managée et qu'aucun élément ne satisfait la définition LRU, le pilote doit utiliser la propriété Priority pour déterminer quelle ressource mémoire managée supprimer de la mémoire vidéo.
Vous pouvez créer des ressources VertexBuffer, IndexBuffer et Texture dans le pool managé, mais pas de mémoires tampon d'affichage et d'arrière-plan, de tampons de profondeur et de surfaces d'image.
Vous pouvez utiliser une instance de la structure SurfaceCaps pour déterminer quels pools de mémoires sont accessibles lorsque vous créez une ressource.
Un appareil mobile peut prendre en charge différents pools de mémoires pour différents types de ressources. Les pilotes d'affichage indiquent leur prise en charge du pool de ressources managé avec la propriété SupportsManagedPool de SurfaceCaps. Si cette propriété est true, l'appareil prend en charge le pool managé pour les ressources VertexBuffer, IndexBuffer et Texture. Une application ne peut pas créer de surface depuis le pool managé si le pilote ne prend pas en charge le pool managé. Si l'appareil prend en charge à la fois le système et les pools de mémoire vidéo pour les textures, l'application peut implémenter sa propre méthode de mise en cache en mémoire à l'aide de la méthode UpdateTexture.
L'application peut également forcer une surface à être préchargée dans la mémoire vidéo avec la méthode PreLoad d'un Resource. Avec cette méthode, les octets nécessaires sont ignorés et la surface est immédiatement chargée.
Enfin, l'application peut également forcer la ressource managée à ignorer un certain nombre d'octets avec la méthode ResourceManagerDiscardBytes de Device. Cette méthode prend le nombre d'octets à ignorer comme un argument. Si l'application passe 0, tous les octets managés en mémoire vidéo sont ignorés.
Toutes les méthodes qui contrôlent le Gestionnaire des ressources agissent immédiatement ; elles ne sont pas mises en mémoire tampon dans le tampon de commande. Par ailleurs, elles échouent si l'appareil ne prend pas en charge le pool managé.
Instances et durées de vie des objets
Lors de la gestion des réinitialisations des appareils et de l'utilisation des tampons d'index ou mémoires tampons de vertex, vous devez utiliser les constructeurs adéquats afin que les objets soient créés avec les durées de vie appropriées.
Windows Mobile Direct3D ne prend en charge qu'une seule instance Device à la fois sur un appareil de type Smartphone ou Pocket PC. Vous pouvez utiliser la méthode statique ReleaseD3DMobile de Manager pour supprimer toutes les ressources d'un appareil Direct3D afin de pouvoir démarrer une autre application Windows Mobile Direct3D sur le même Pocket PC ou Smartphone.
Les objets suivants doivent être recréés lorsque Device est réinitialisé. La nouvelle création peut être exécutée dans un gestionnaire d'événements pour l'événement DeviceReset.
Objets Texture.
Objets Mesh.
Objets Surface.
Objets VertexBuffer qui ont été créés avec le constructeur VertexBuffer(Device, Int32, Usage, VertexFormats, Pool).
Objets IndexBuffer qui ont été créés avec le constructeur IndexBuffer(Device, Int32, Usage, Pool, Boolean).
Les objets suivants ne doivent pas être recréés lorsque Device est réinitialisé :
Objets Font.
Objets Sprite.
Objets VertexBuffer créés avec le constructeur VertexBuffer(Type, Int32, Device, Usage, VertexFormats, Pool).
Objets IndexBuffer créés avec le constructeur IndexBuffer(Type, Int32, Device, Usage, Pool).
Les objets Font et Sprite exécutent automatiquement toutes les actions nécessaires en réponse à la réinitialisation de l'appareil.
Les objets IndexBuffer et VertexBuffer se recréent automatiquement lorsqu'un appareil est réinitialisé, mais ils ne contiendront aucune donnée. Vous pouvez définir un gestionnaire d'événements pour l'événement IndexBuffer.Created ou VertexBuffer.Created pour remplir l'index ou la mémoire tampon de vertex avec des données une fois que l'appareil est réinitialisé.
Voir aussi
Autres ressources
Programmation Direct3D Mobile dans le .NET Compact Framework