Verwalten von Geräteressourcen
Aktualisiert: November 2007
Bei der Programmierung im verwalteten Mobile Direct3D-Programmiermodell stehen Ihnen zwei grundlegende Ressourcentypen zur Verfügung: Ressourcen, die nach dem Zurücksetzen des Geräts wiederhergestellt werden müssen, und Ressourcen, bei denen dies nicht erforderlich ist. Manche Objekttypen dürfen nach dem Zurücksetzen eines Geräts mit Daten gefüllt werden, andere nicht. Im Gegensatz zu Direct3D in Desktopanwendungen ist der Speicherpool, der für die Erstellung einer Ressource verwendet wird, nicht wichtig für die Entscheidung, ob eine Ressource nach dem Zurücksetzen neu erstellt werden muss.
Speicherpooling
Drei Speicherpools sind im verwalteten Mobile Direct3D-Programmiermodell verfügbar:
System
Die Reservierung erfolgt im normalen Systemspeicher auf dem mobilen Gerät. Die Ausführung dauert in diesem Fall länger als im Videospeicher.
Video
Reserviert einen Arbeitsspeicherbereich, der hauptsächlich von Videohardware auf dem mobilen Gerät genutzt wird. Auf einigen Geräten kann der Videospeicher möglicherweise eine stark eingeschränkte Ressource sein.
Verwalteter Arbeitsspeicher
Reserviert Videospeicher als Cache des Systemspeichers. Der Treiber kann verschiedene Algorithmen wie den Ersetzungsalgorithmus LRU (Least Recently Used – am längsten nicht verwendet) einsetzen, um das Zwischenspeicherungsablaufschema zu implementieren.
Wird im verwalteten Speicherpool eine Textur oder eine andere Ressource erstellt, wird der Textur im Systemspeicherpool Speicherplatz zugeordnet. Wenn die Textur mit der SetTexture-Methode einer Texturebene zugewiesen wird, wird sie in den Videospeicherpool geuploadet. Dort verbleibt sie, bis sie schließlich als am längsten nicht verwendetes Element zugunsten anderer Ressourcen entfernt wird. Wenn im Videospeicher Speicherplatz freigegeben werden muss, um eine verwaltete Oberfläche zu uploaden, und kein Element der Definition eines am längsten nicht verwendeten Elements entspricht, sollte der Treiber die Priority-Eigenschaft verwenden, um zu bestimmen, welche verwaltete Speicherressource aus dem Videospeicher entfernt wird.
Sie können die Ressourcen VertexBuffer, IndexBuffer und Texture im verwalteten Pool erstellen, aber keine Vordergrund- und Hintergrundpuffer, Tiefenpuffer und Bildoberflächen.
Über eine Instanz der SurfaceCaps-Struktur können Sie feststellen, auf welche Speicherpools beim Erstellen einer Ressource zugegriffen werden kann.
Ein mobiles Gerät kann verschiedene Speicherpools für unterschiedliche Ressourcentypen unterstützen. Videotreiber zeigen mithilfe der SupportsManagedPool-Eigenschaft von SurfaceCaps ihre Unterstützung für den verwalteten Ressourcenpool an. Wenn diese Eigenschaft true lautet, unterstützt das Gerät den verwalteten Pool für die Ressourcen VertexBuffer, IndexBuffer und Texture. Eine Anwendung kann aus dem verwalteten Pool keine Oberfläche erstellen, wenn der Treiber den verwalteten Pool nicht unterstützt. Wenn das Gerät sowohl System- als auch Videospeicherpools für Texturen unterstützt, kann die Anwendung mithilfe der UpdateTexture-Methode ihr eigenes Zwischenspeicherungsablaufschema implementieren.
Die Anwendung kann auch erzwingen, dass eine Oberfläche mit der PreLoad-Methode von Resource vorab in den Videospeicher geladen wird. Diese Methode bewirkt, dass die notwendigen Bytes verworfen werden und die Oberfläche sofort geladen wird.
Außerdem zwingt die Anwendung die verwaltete Ressource möglicherweise dazu, mit der ResourceManagerDiscardBytes-Methode von Device eine vorgegebene Anzahl von Bytes zu verwerfen. Diese Methode akzeptiert die Anzahl von Bytes, die als Argument verworfen werden sollen. Wenn die Anwendung 0 übergibt, werden alle verwalteten Bytes im Videospeicher verworfen.
Alle Methoden, die den Ressourcen-Manager steuern, treten sofort in Aktion und werden nicht im Befehlspuffer gepuffert. Bei ihrer Ausführung tritt ein Fehler auf, wenn das Gerät den verwalteten Pool nicht unterstützt.
Instanzen und Lebensdauer von Objekten
Bei der Verwaltung von Geräterücksetzungen und der Verwendung von Indexpuffern oder Vertexpuffern sind entsprechende Konstruktoren einzusetzen, sodass Objekte mit geeigneter Lebensdauer erstellt werden.
Windows Mobile Direct3D unterstützt pro Smartphone oder Pocket PC nur jeweils eine Device-Instanz. Mit der statischen ReleaseD3DMobile-Methode von Manager können Sie alle Direct3D-Geräteressourcen entfernen. Anschließend können Sie eine andere Windows Mobile Direct3D-Anwendung auf demselben Pocket PC oder Smartphone starten.
Folgende Objekte müssen nach dem Zurücksetzen von Device neu erstellt werden. Die Wiedererstellung kann in einem Ereignishandler für das DeviceReset-Ereignis ausgeführt werden.
Texture-Objekte.
Mesh-Objekte.
Surface-Objekte.
VertexBuffer-Objekte, die mit dem VertexBuffer(Device, Int32, Usage, VertexFormats, Pool)-Konstruktor erstellt wurden.
IndexBuffer-Objekte, die mit dem IndexBuffer(Device, Int32, Usage, Pool, Boolean)-Konstruktor erstellt wurden.
Die folgenden Objekte müssen nicht neu erstellt werden, wenn ein Device zurückgesetzt wird:
Font-Objekte.
Sprite-Objekte.
Mit dem VertexBuffer(Type, Int32, Device, Usage, VertexFormats, Pool)-Konstruktor erstellte VertexBuffer-Objekte.
Mit dem IndexBuffer(Type, Int32, Device, Usage, Pool)-Konstruktor erstellte IndexBuffer-Objekte.
Das Font-Objekt und das Sprite-Objekt führen als Folge einer Geräterücksetzung automatisch alle notwendigen Aktionen aus.
Das IndexBuffer-Objekt und das VertexBuffer-Objekt erstellen sich automatisch selbst neu, wenn ein Gerät zurückgesetzt wird. Sie enthalten dann allerdings keine Daten. Sie können für das IndexBuffer.Created-Ereignis und das VertexBuffer.Created-Ereignis einen Ereignishandler definieren, mit dem der Index- oder Vertexpuffer nach dem Zurücksetzen mit Daten gefüllt wird.