Programmierhandbuch für Kompositions-Swapchain
Die Kompositions-Swapchain-API ist der Nachfolger der DXGI-Swapchain, die es Anwendungen ermöglicht, Inhalte zu rendern und auf dem Bildschirm anzuzeigen. Diese API anstelle der DXGI-Swapchain zu nutzen hat diverse Vorteile. Ihre Anwendung kann den Swapchain-Status präziser kontrollieren, und die Swapchain kann viel flexibler genutzt werden. Zusätzlich bietet die API eine bessere Story für eine genaue Present-Zeitplanung.
Was versteht man unter „Darstellung“?
Als Darstellung bezeichnet man das Konzept, dass die Ergebnisse von Zeichenvorgängen auf dem Bildschirm angezeigt werden. Ein Present ist eine einzelne Instanz einer Darstellung, also eine Anforderung, die Ergebnisse eines Zeichenvorgangs in einem einzigen Puffer auf dem Bildschirm anzuzeigen. Ein Present kann weitere Attribute umfassen, mit denen die Art und Weise der Anzeige auf dem Bildschirm beschrieben wird. Bei dieser API kann ein Present auch eine Zielzeit aufweisen. Das ist ein Zeitstempel in Relation zum System (eine Unterbrechungszeit), der den idealen Zeitpunkt vorgibt, zu dem das Present angezeigt werden sollte. Damit ist Ihre Anwendung in der Lage, die Frequenz für die Anzeige von Inhalten auf dem Bildschirm präziser zu steuern und Presents mit anderen Ereignissen im System, wie einer Tonspur, zu synchronisieren.
Herzstück der Darstellung ist die Synchronisierung. Zeichenvorgänge werden üblicherweise von einem Grafikprozessor (GPU) ausgeführt, nicht von der CPU. Die Ausführung dieser Vorgänge erfolgt daher asynchron zur CPU, die die Vorgänge ursprünglich ausgegeben hat. Eine Darstellung ist ein Vorgang, der an die GPU übergeben wird und dafür sorgt, dass die Zeichenvorgänge, die zuvor ausgegeben wurden, vor der Anzeige des Puffers auf dem Bildschirm abgeschlossen sind.
Ihre Anwendung gibt für gewöhnlich mit der Zeit zahlreiche Presents aus und hat bei der Ausgabe die Auswahl aus mehreren Texturen. Ihre Anwendung muss mit den Mechanismen dieser API für die Synchronisierung gewährleisten, dass Sie in einen Puffer, in den Sie gezeichnet und den Sie angezeigt haben, erst wieder zeichnen, wenn dieses Present angezeigt und danach durch einen anderen Puffer eines nachfolgenden Presents ersetzt wurde. Ansonsten kann es dazu kommen, dass die Inhalte des Puffers, den Ihre Anwendung zunächst anzeigen wollte, überschrieben werden, wenn dieses Present auf dem Bildschirm angezeigt wird.
Darstellungsmodi – Komposition, mehrschichtige Überlagerung und unabhängiges Spiegeln
Für die Anzeige der von Ihrer Anwendung präsentierten Puffer durch das System gibt es unterschiedliche Möglichkeiten.
Die einfachste – und standardmäßige – besteht darin, dass das Present an den DWM übermittelt wird und der DWM basierend auf dem präsentierten Puffer einen Frame rendert. Der Darstellungspuffer wird also in den Hintergrundpuffer kopiert (bzw. genauer gesagt: ein 3D-Rendering wird erzeugt), den der DWM an die Anzeige übermittelt. Diese Anzeigemethode für Presents nennt man Komposition.
Eine leistungsfähigere Methode für die Anzeige von Presents besteht darin, den Darstellungspuffer direkt zur Hardware zu scannen und die erfolgte Kopie zu löschen. Diese Anzeigemethode für Presents nennt man direktes Scanout. Bei der Verarbeitung von Presents kann der DWM beschließen, die Hardware für einen direkten Scanout eines Darstellungspuffers zu programmieren. Dazu weist er den Puffer einer Ebene mit mehrschichtiger Überlagerung zu oder spiegelt den Puffer direkt auf die Hardware (direktes Spiegeln).
Eine noch bessere Leistung bei der Anzeige von Presents lässt sich erreichen, wenn Presents den DWM komplett umgehen und direkt vom Grafikkernel angezeigt werden. Diese Methode für die Darstellung nennt man unabhängiges Spiegeln (iflip). Die mehrschichtige Überlagerung und das direkte Spiegeln sind unter Verwenden Sie das DXGI-Flipmodell, um eine optimale Leistung zu erzielen beschrieben.
Die Kompositionsmethode lässt sich am leichtesten unterstützen, sie bietet aber auch die niedrigste Effizienz. Damit die Oberfläche für das direkte Scanout oder für iflip infrage kommt, muss sie eigens zugeteilt werden. Für diese Art der besonderen Zuteilung gelten striktere Systemanforderungen als für die Kompositions-Swapchain. Sie steht nur auf Hardware mit WDDM 3.0 und höher zur Verfügung. Infolgedessen kann Ihre Anwendung die API-Unterstützung für eine reine Kompositionsdarstellung abfragen als auch für eine Darstellung, die sich für das direkte Scanout oder für iflip eignet.
Hinweis
Sie müssen Ihre Oberflächen für die direkte Anzeige durch die GPU zuteilen, damit sie diese besseren Darstellungsmodi automatisch verwenden können. Bei Direct3D 11-Oberflächen ist die Zuteilung Ihrer Oberflächen als anzeigbar erforderlich. Oberflächen, die Sie nicht als anzeigbar zuteilen, kann der System-Compositor dennoch auf dem Bildschirm anzeigen. Die Vorteile des unabhängigen Spielens lassen sich auf diese Weise aber nicht erzielen.
Darstellungsfactory, Überprüfungsfunktion und Darstellungsmanager
Die Darstellungsfactory ist das erste Objekt der Kompositions-Swapchain-API, das von Ihrer Anwendung verwendet wird. Diese Darstellungsfactory wird von Ihrer Anwendung erzeugt und an ein Direct3D-Gerät gebunden, das die Anwendung zur Erstellung an den Aufruf übergibt. Aus diesem Grund besitzt sie eine Affinität zu dem Videoadapter, der mit diesem Gerät verknüpft ist.
Die Darstellungsfactory bietet Methoden, mit denen geprüft werden kann, ob das aktuelle System und das Grafikgerät die Kompositions-Swapchain-API nutzen können. Ob das System diese Unterstützung bietet, können Sie mit Funktionsmethoden wie IPresentationFactory::IsPresentationSupported nachprüfen. Wenn diese Überprüfung ergibt, dass die API vom System unterstützt wird, können Sie mit der Darstellungsfactory einen Darstellungsmanager erzeugen. Bei diesem Darstellungsmanager handelt es sich um das Objekt, mit dem Darstellungsfunktionen ausgeführt werden. Er wird an dasselbe Direct3D-Gerät und denselben Videoadapter gebunden wie die Darstellungsfactory, mit der er erzeugt wurde.
Aktuell setzt die Nutzung der Kompositions-Swapchain-API Grafikkartentreiber, die WDDM (Windows Device Driver Model) 2.0 unterstützen, und Windows 11 (Build 10.0.22000.194) oder höher voraus. Um die Kompositions-Swapchain-API mit der höchstmöglichen Leistung nutzen zu können (direktes Scanout und unabhängiges Spiegeln bzw. iflip), muss das System Grafikkartentreiber umfassen, die WDDM 3.0 unterstützen.
Falls das System die Kompositions-Swapchain-API nicht unterstützt, benötigt Ihre Anwendung einen gesonderten Codepfad für die Darstellung mit älteren Methoden wie der DXGI-Swapchain.
Registrierung von Darstellungspuffern für die Anzeige
Der Darstellungsmanager verfolgt die Puffer nach, die er anzeigen kann. Für die Anzeige einer Direct3D-Textur muss Ihre Anwendung als erstes mit Direct3D diese Textur erstellen und sie anschließend beim Darstellungsmanager registrieren. Nach der Registrierung beim Darstellungsmanager wird eine Textur Darstellungspuffer genannt, und der Darstellungsmanager kann sie ab sofort zur Anzeige auf dem Bildschirm übergeben. Ihre Anwendung kann ganz nach Ihren Wünschen Darstellungspuffer hinzufügen und entfernen. Die Anzahl der Darstellungspuffer, die Sie zu einem einzigen Darstellungsmanager hinzufügen können, ist allerdings beschränkt (aktuell auf 31 Puffer). Diese Darstellungspuffer können verschiedene Größen und Formate aufweisen, die wirksam werden, wenn ein einzelner Darstellungspuffer präsentiert wird.
Sie können eine Textur bei so vielen Darstellungsmanagern registrieren, wie Sie möchten. In den meisten Fällen gilt dies allerdings nicht als übliche Nutzung und hat komplexe Synchronisierungsszenarien zur Folge, die Ihre Anwendung verwalten müsste.
Definition der Inhalte, die angezeigt werden sollen
Generell müssen die Puffer, die angezeigt werden sollen, in einer visuellen Struktur mit Inhalten verknüpft werden. Zu diesem Zweck müssen wir eine Art von Bindung definieren, damit ersichtlich ist, an welche Stelle der visuellen Struktur die präsentierten Puffer gehören, wenn Ihre Anwendung Presents ausgibt. Diese Bindung nennen wir Darstellungsinhalt.
Darstellungsinhalte können ganz unterschiedliche Formen annehmen Vielleicht will Ihre Anwendung einen einzigen Puffer für die Anzeige präsentieren oder Stereo-Inhalte, die Puffer für das linke und das rechte Auge enthalten, usw. Die ursprüngliche Version dieser API unterstützt die Anzeige eines einzigen Puffers auf dem Bildschirm.
Unter einer Darstellungsoberfläche verstehen wir eine Form des Darstellungsinhalts, der immer nur ein einziger Puffer präsentiert wird. Sie können eine Darstellungsoberfläche in einer visuellen Struktur als Inhalt festlegen. Diese Oberfläche kann immer nur einen einzigen Darstellungspuffer auf dem Bildschirm anzeigen. Der Puffer, den mindestens eine Darstellungsoberfläche atomar anzeigt, wird durch die Presents des Darstellungsmanagers aktualisiert.
Mit dem Darstellungsmanager lässt sich eine Darstellungsoberfläche oder auch mehrere davon für einen angegebenen Handle einer Kompositionsoberfläche erstellen. Jedes Handle einer Kompositionsoberfläche lässt sich an mindestens eine visuelle Komponente in einer visuellen Struktur binden, damit die Beziehung zwischen der verknüpften Darstellungsoberfläche und ihrer Position in der visuellen Struktur definiert wird. (Die Schritte zur Bindung der Handles werden in der Dokumentation zu den APIs Windows.UI.Composition und DirectComposition erläutert.) Die Darstellungsoberflächen können durch Ihre Anwendung aktualisiert werden und werden dann an das System für den nächsten Anzeigevorgang übergeben.
Hinweis: Der Darstellungsmanager kann jeden beliebigen Darstellungspuffer beliebig vielen Darstellungsoberflächen präsentieren. Es gibt keine Einschränkungen. Ihre Anwendung muss allerdings nachverfolgen, welche Puffer Sie an welcher Stelle ausgegeben haben. Nur so kann sie gewährleisten, dass keine neuen Zeichnungen in diesen Puffer geschrieben werden, während er noch auf der Darstellungsoberfläche angezeigt wird.
Anwendung von Eigenschaften für Darstellungsoberflächen
Ein Present kann nicht nur die Puffer für die Anzeige auf einer Darstellungsoberfläche vorgeben, sondern auch diverse weitere Eigenschaften für diese Darstellungsoberfläche festlegen. Das umfasst beispielsweise Eigenschaften, die die Sampling-Art für die Quelltextur wie Alpha-Modus und Farbraum festlegen, die Umwandlung und Anordnung der Quelltextur vorgeben oder die angezeigten oder eingelesenen Einschränkungen für geschützte Inhalte definieren. Diese Methoden werden als Eigenschaft-Setter-Methoden auf einer Darstellungsoberfläche bereitgestellt. Sie können durch Ihre Anwendung geändert werden und werden – ebenso wie Aktualisierungen von Puffern – wirksam, wenn das Present Ihrer Anwendung angezeigt wird.
Anzeige auf der Darstellungsoberfläche
Wenn Ihre Anwendung die Darstellungsoberflächen erstellt, die Darstellungspuffer registriert und die Aktualisierung festgelegt hat, die bei einer Anzeige auszugeben sind, können Sie diese Eigenschaften durch das Anzeigen übernehmen. Ihre Anwendung gibt über den Darstellungsmanager ein Present aus. Wenn das System dieses Present verarbeitet, werden die Aktualisierungen allesamt atomar vorgenommen. Zusätzlich können auch andere Eigenschaften des Presents durch Ihre Anwendung festgelegt werden, darunter die ideale Zeit für die Durchführung (die Zielzeit für das Present) und sonstige weniger gebräuchliche Eigenschaften, beispielsweise die gewünschte Inhaltsfrequenz, mit der individuelle Wiederholungsmodi auf dem System aktiviert werden können. Weil Presents für eine bestimmte Zeit geplant werden können, ist es Ihrer Anwendung möglich, mehrere Presents vorzeitig auszugeben. Zum geplanten Zeitpunkt werden diese Presents dann der Reihe nach verarbeitet.
Synchronisierung der Darstellung
Beim Rendern in Puffer und bei der Ausgabe von Presents muss Ihre Anwendung gewährleisten können, dass sie für das Rendern einen Puffer auswählt, auf den gegenwärtig kein sonstiges zuvor ausgegebenes Present verweist – dabei könnten die vorhandenen Inhalte des Puffers überschrieben werden. Wenn Ihre Anwendung das Rendering in einen Puffer veranlasst, der aktuell von einer Darstellungsoberfläche auf Scanout-Hardware angezeigt wird, kann überdies das Rendering auf unbestimmte Zeit zum Stillstand kommen, weil Frontpuffer-Rendering bei Direct3D nicht zulässig ist.
Mit der Kompositions-Swapchain-API stehen mehrere Mechanismen zur Verfügung, mit denen Ihre Anwendung die angezeigten Puffer korrekt synchronisieren kann.
Ein Puffer gilt als verfügbar, wenn keine ausstehenden Presents mehr auf ihn verweisen und er aktuell nicht mehr vom System angezeigt wird. Ansonsten gilt er als nicht verfügbar. Die API liefert für jeden Darstellungspuffer ein Ereignis, das darauf hinweist, ob der Puffer verfügbar ist oder nicht. Dies ist die einfachste Möglichkeit, wie Ihre Anwendung die Synchronisierung vornehmen kann. Bevor sie in einen Puffer zeichnet und ihn anzeigt, kann Ihre Anwendung überprüfen, ob das Ereignis „Verfügbar“ des Puffers gemeldet wird. Das Ereignis „Verfügbar“ eines bestimmten Puffers wird nicht mehr gemeldet, sobald der Puffer in der API an eine Darstellungsoberfläche gebunden wird, und es wird nicht mehr gemeldet, bis das Present eingestellt wird.
Zum Zweiten verfolgt der Darstellungsmanager den Zeitraum für die Einstellung eines einzelnen Presents nach, damit er Ihrer Anwendung melden kann, welche Presents abgeschlossen wurden. Der Wert des Zeitraums stimmt mit der Present-ID des letzten Presents überein, das die Einstellungsphase seines Lebenszyklus eingeläutet hat. Weitere Informationen finden Sie Abschnitt Lebenszyklus weiter unten. Wenn sich ein Present in dieser Phase befindet, kann man davon ausgehen, dass Puffer, die durch darauf folgende Presents ersetzt wurden, erneut genutzt werden können.
Diese Synchronisierungsmethode ist fortschrittlicher. Sie lässt aber eine stärkere Kontrolle der Workflow-Drosselung zu und kann genauere Informationen zum Systemstatus hinsichtlich der Länge der derzeitigen Present-Warteschlange liefern. Der nächste Abschnitt enthält einen Überblick über den Lebenszyklus von Presents
Lebenszyklus eines Presents
Die Presents des Darstellungsmanagers werden in einer Present-Warteschlange in eine Warteschlange für das System gesetzt. Die Presents werden in der Reihenfolge, in der sie sich in der Warteschlange befinden, vom System verarbeitet. Zusätzlich ist mit jedem Present eine (für den Darstellungsmanager) eindeutige Present-ID verknüpft. Bei dieser ID handelt es sich um einen Wert, der einem Present zugewiesen wird – beim ersten Present lautet der Wert 1, bei allen weiteren Presents erhöht sich der Wert jeweils um 1. Mit dieser Present-ID wird in unterschiedlichen Teilen der API, beispielsweise bei Synchronisierungsprimitiven und in Darstellungsstatistiken, auf das konkrete Present verwiesen.
Jedes Present, das Ihre Anwendung ausgibt, durchläuft einen spezifischen Lebenszyklus, der hier beschrieben wird.
Wenn Ihre Anwendung die Änderungen konfiguriert, die als Teil eines Presents durchzuführen sind, gibt sie das Present mit dem Darstellungsmanager aus. Zu diesem Zeitpunkt gilt das Present als ausstehend.
Ein ausstehendes Present befindet sich in der Present-Warteschlange des Darstellungsmanagers, bis eines von zwei Ereignissen auftritt.
- Das Present wird abgebrochen. Mit dem Darstellungsmanager kann Ihre Anwendung bereits ausgegebene Presents abbrechen. Wenn dies geschieht, gilt das Present als abgebrochen und wird umgehend eingestellt. Bei dieser Veränderung werden „Verfügbar“-Ereignisse des verknüpften Puffers für das abgebrochene Present aktualisiert. Der Einstellungszeitraum des Presents wird allerdings nicht gemeldet, weil das zuvor angezeigte Present (vor den abgebrochenen Presents) weiterhin angezeigt wird. Daher kann Ihre Anwendung anhand des Einstellungszeitraums des Presents nicht ermitteln, welche Presents abgebrochen wurden. Diese Informationen können Sie stattdessen der Statistik zum Present-Status entnehmen, die für jedes abgebrochene Present erzeugt wird. Es wird empfohlen, dass Ihre Anwendung nach einem Abbruch mit den „Verfügbar“-Ereignissen des Puffers einen verfügbaren Puffer für die Anzeige sucht. Wenn dieses Present angezeigt wird, startet die Einstellung des vorherigen Presents und der Einstellungszeitraum des Presents wird aktualisiert.
- Wenn das Present nicht abgebrochen wird, ist es letztendlich bereit für die Verarbeitung. Für die Bereitschaft müssen zwei wichtige Bedingungen erfüllt sein.
- Alle Zeichenvorgänge, die vor dem Aufruf des Presents für den Direct3D-Kontext ausgegeben wurden, müssen abgeschlossen sein. Damit wird gewährleistet, dass der Puffer erst angezeigt wird, wenn die Zeichnung Ihrer Anwendung abgeschlossen ist.
- Falls eine Zielzeit für das Present festgelegt wurde, stimmt die aktuelle Systemzeit, zu der die Anzeige des Presents möglich sein sollte, mit der angeforderten Zielzeit überein, die von Ihrer Anwendung auf das Present angewendet hat.
Wenn das System ein Present für die Anzeige auf dem Bildschirm sucht, wählt es das letzte Present aus, das bereit für die Anzeige wurde. Falls mehrere Presents bereit sind, werden alle bis auf das jüngste (also das Present mit der höchsten Present-ID) übersprungen und umgehend in den Status Eingestellt versetzt. Daraufhin werden die „Verfügbar“-Ereignisse seines Puffers gemeldet. Der Einstellungszeitraum des Presents wird aber nicht gemeldet, weil das übersprungene Present im Status angezeigt verbleibt.
Wenn das bereite Present für die Anzeige ausgewählt wird, initiiert das System die nötigen Vorgänge für die Anzeige auf dem Bildschirm. Dazu kann beispielsweise das Rendering des Puffers als Teil eines DWM-Frames gehören, gefolgt von der Anforderung, dass die Hardware diesen Frame auf dem Bildschirm anzeigt. Es kann sich aber auch darum handeln, dass der Puffer im iflip-Verfahren direkt an die Scanout-Hardware übermittelt wird. Nachdem diese Vorgänge durchgeführt wurden, gilt das Present als in der Warteschlange. Grob gesehen heißt das, dass das Present auf dem Weg ist, angezeigt zu werden.
Wenn die Hardware das Present schließlich anzeigt, gilt das Present als angezeigt. Es wird solange auf dem Bildschirm angezeigt, bis es durch das nächste Present ersetzt wird.
Wenn ein nachfolgendes Present die Warteschlange erreicht, ist klar, dass die Hardware irgendwann die Anzeige des aktuellen Presents beendet. Zu diesem Zeitpunkt gilt das Present als in der Einstellungsphase.
Wenn das nachfolgende Present angezeigt wird, gilt das aktuelle Present als eingestellt.
Der Darstellungsmanager stellt einen Einstellungszeitraum für das Present aus, welcher der Present-ID jedes Presents gemeldet wird, wenn es in den Status in der Einstellungsphase übergeht. Anhand dieser Meldung weiß Ihre Anwendung, dass sie den Puffern, die mit diesem Present verknüpft sind, sicher Rendering-Aufgaben übergeben kann, ohne dass ein vorhergehendes Present beschädigt wird. Wenn Ihre Arbeit Rendering-Aufgaben ausgibt, solange sich das Present im Status in der Einstellungsphase befindet, werden die Rendering-Aufgaben in die Warteschlange gestellt, bis das Present in den Status eingestellt wechselt. Dann werden die Aufgaben ausgeführt. Werden die Rendering-Aufgaben ausgegeben, nachdem das Present eingestellt wurde, werden sie unverzüglich ausgeführt.
Nachfolgend sehen Sie ein Diagramm, das diese Statusänderung illustriert.
Diagramm mit Puffern, Oberflächen und Presents
Das folgende Diagramm zeigt den Darstellungsmanager, die Darstellungspuffer, die Darstellungsoberflächen, die Presents und Aktualisierungen.
Es zeigt einen Darstellungsmanager mit zwei Darstellungsoberflächen und drei Darstellungspuffern. Dieser hat bislang zwei ausgegebene Presents erhalten. Das erste Present zeigte den 1. Puffer in der 1. Oberfläche und den 2. Puffer in der 2. Oberfläche an. Das zweite Present aktualisierte die 2. Oberfläche, sodass sie den 3. Darstellungspuffer anzeigt. Die Bindung der 1. Oberfläche wurde nicht geändert. Nachdem das 2. Present angezeigt wurde, zeigt die 1. Oberfläche den 1. Puffer und die 2. Oberfläche den 3. Puffer. Dies ist anhand des aktuellen Status der Objekte im Darstellungsmanager zu erkennen. Jedes Present aus der Warteschlange wird wirksam, wenn es vom System verarbeitet wird.
Hinweis
Weil das 2. Present den Puffer für die 1. Oberfläche nicht verändert hat, blieb die 1. Oberfläche an den 1. Puffer des vorhergehenden Presents gebunden. Insofern liegt im 2. Present ein „impliziter“ Verweis auf den 1. Puffer vor, weil die Bindung der 1. Oberfläche an den 1. Puffer auch nach der Anzeige des 2. Presents bestehen bleibt.
Hinzufügen von Darstellungsoberflächen zur visuellen Struktur
Bei Darstellungsoberflächen handelt es sich um Inhalte, die als Komponente einer visuellen Struktur einer Komposition vorliegen. Jede Darstellungsoberfläche ist an ein Handle einer Kompositionsoberfläche gebunden. In Windows.UI.Composition besteht die Möglichkeit, für einen vorhanden Handle einer Kompositionsoberfläche einen Oberflächenpinsel zu erstellen und an ein visuelles Sprite-Element zu binden. In DirectComposition ist es möglich, aus einem vorhandenen Handle einer Kompositionsoberfläche eine Kompositionsoberfläche zu erstellen und sie als Inhalt an ein visuelles Element zu binden. Weitere Informationen hierzu finden Sie in der Dokumentation für die jeweilige API.
APIs wie Windows Media Foundation, die auf die Nutzung dieser API ausgelegt sind, stellen Handles für eine Kompositionsoberfläche aus, die vorab an eine Darstellungsoberfläche gebunden werden. Darüber hinaus kann eine Anwendung auch einen eigenen Handle einer Kompositionsoberfläche erstellen. Diesen Handle kann sie daraufhin an eine Darstellungsoberfläche binden und zu einer visuellen Struktur hinzufügen, indem Sie DCompositionCreateSurfaceHandle aufruft.
Lesen der Darstellungsstatistiken
Die Kompositions-Swapchain-API stellt Darstellungsstatistiken zur Verfügung, die diverse Informationen zur Verarbeitung eines konkreten Presents enthalten. Diese Angaben sagen beispielsweise aus, auf welche Weise eine Darstellungsoberfläche in einem DWM-Frame genutzt wurde, zu welchem Zeitpunkt sie angezeigt wurde, ob sie angezeigt wurde usw.
Von diesen Darstellungsstatistiken gibt es unterschiedliche Arten. In zukünftigen Versionen der API sollen sie auch erweiterbar sein. Mit dem Darstellungsmanager meldet sich eine Anwendung für den Erhalt der Statistikarten an, die für sie relevant sind. Daraufhin werden diese Statistiken in die Statistik-Warteschlange des Darstellungsmanagers gestellt. Der Darstellungsmanager zeigt den Anwendungen das „Statistiken verfügbar“-Ereignis an. Dieser Ereignishandle weist darauf hin, dass in einer Statistik-Warteschlange Statistikobjekte zum Lesen verfügbar sind. Wenn dies der Fall ist, entnimmt Ihre Anwendung das erste Statistikobjekt aus der Warteschlange, liest es und verarbeitet es. Wenn alle Statistiken, die aktuell in der Warteschlange stehen, von Ihrer Anwendung gelesen wurden, wird das „Statistiken verfügbar“-Ereignis vom Darstellungsmanager zurückgesetzt. Üblicherweise werden Statistiken von einer Anwendung in einer Schleife gelesen und verarbeitet, bis das „Statistiken verfügbar“-Ereignis zurückgesetzt wurde. Häufig wird Ihre Anwendung diese Statistik-Warteschlange in derselben Aufgabenschleife verarbeiten, die auch für die Ausgabe von Presents genutzt wird. Als Nutzungsmuster wird empfohlen, der Verarbeitung von Statistiken eine höhere Priorität zuzuweisen als der Ausgabe neuer Presents. Damit lässt sich ein Überlauf der Warteschlange verhindern.
Für die Anzahl der Statistiken, die die Warteschlange nachverfolgt, gilt ein Höchstwert, der zwischen 512 und 1024 liegt. Die Höchstlänge der Warteschlange sollte genügen, dass im Normalfall etwa 5 Sekunden an Statistiken gespeichert werden. Wenn die Statistik-Warteschlange voll wird und noch weitere Statistiken eingehen, wird die älteste Statistik aus der Warteschlange entfernt, damit die neue gespeichert werden kann.