Programmierhandbuch für Kompositions-Swapchain

Die Kompositions-Swapchain-API ist ein spiritueller Nachfolger der DXGI-Swapchain, mit der Anwendungen Inhalte rendern und auf dem Bildschirm präsentieren können. Die Verwendung dieser API gegenüber der DXGI-Swapchain bietet mehrere Vorteile. Ihre Anwendung erhält eine präzisere Kontrolle über den Zustand der Swapchain, und es wird mehr Freiheit gewährt, wenn es darum geht, wie die Swapchain verwendet wird. Darüber hinaus bietet die API eine bessere Geschichte für eine präzise zeitgenaue Zeitplanung.

Was ist Präsentation?

Präsentation ist das Konzept der Anzeige der Ergebnisse von Zeichnungsvorgängen auf dem Bildschirm. Ein Geschenk ist ein einzelner instance der Präsentation– eine Anforderung, die Ergebnisse eines Zeichnungsvorgangs auf einem einzelnen Puffer auf dem Bildschirm anzuzeigen. Ein Geschenk kann zusätzliche Attribute enthalten, die beschreiben, wie auf dem Bildschirm angezeigt wird. In dieser API kann ein Geschenk auch eine Zielzeit haben, d. h. einen systemrelativen Zeitstempel (eine Unterbrechungszeit), die die ideale Zeit beschreibt, zu der die Gegenwart angezeigt werden soll. Ihre Anwendung kann dies verwenden, um die Geschwindigkeit, mit der Inhalte auf dem Bildschirm angezeigt werden, genauer zu steuern, und um Darstellungen mit anderen Ereignissen im System, z. B. einer Audiospur, zu synchronisieren.

Im Mittelpunkt der Präsentation steht die Synchronisierung. Das heißt, Zeichnungsvorgänge werden in der Regel von einer GPU ausgeführt, im Gegensatz zur CPU und als solche werden sie auf einem asynchronen Zeitleiste von der CPU ausgeführt, die die Vorgänge ursprünglich ausgegeben hat. Presentation ist ein An die GPU übermittelter Vorgang, der sicherstellt, dass die zuvor ausgegebenen Zeichnungsvorgänge abgeschlossen sind, bevor der Puffer auf dem Bildschirm angezeigt wird.

Ihre Anwendung stellt im Laufe der Zeit in der Regel viele Geschenke aus und verfügt über mehrere Texturen, aus denen Sie beim Ausstellen von Geschenken auswählen können. Ihre Anwendung muss die von dieser API bereitgestellten Synchronisierungsmechanismen verwenden, um sicherzustellen, dass Sie nach dem Zeichnen und Präsentieren eines Puffers nicht erneut in diesen Puffer zeichnen, bis dieser vorhanden angezeigt und anschließend durch einen neuen Puffer aus einem nachfolgenden Geschenk ersetzt wurde. Andernfalls kann der Pufferinhalt, den Ihre Anwendung ursprünglich präsentieren wollte, überschrieben werden, da dieser auf dem Bildschirm angezeigt wird.

Präsentationsmodi – Komposition, Mehrebenenüberlagerung und iflip

Puffer, die von Ihrer Anwendung angezeigt werden, können vom System auf verschiedene Arten angezeigt werden.

Die einfachste Methode, die standardmäßig ist, besteht darin, dass das Vorhandene an DWM gesendet wird, und der DWM einen Frame basierend auf dem angezeigten Puffer rendert. Das heißt, es gibt eine Kopie (oder genauer gesagt ein 3D-Rendern) des Präsentationspuffers in den Backbuffer, den der DWM an die Anzeige sendet. Diese Methode zum Anzeigen eines Gegenwarts wird Composition genannt.

Ein leistungsfähigerer Modus zum Anzeigen eines Geschenks besteht darin, den Präsentationspuffer direkt auf die Hardware auszuscannen und den Kopiervorgang zu beseitigen. Diese Methode zum Anzeigen eines Gegenwarts wird als direktes Scanout bezeichnet. Beim Behandeln von Präsentationen kann DWM entscheiden, die Hardware so zu programmieren, dass sie direkt aus einem Präsentationspuffer scannt, indem der Puffer entweder einer Mehrschichtebene (oder einer MPO-Ebene, kurz MPO-Ebene) zugewiesen wird, oder den Puffer direkt auf die Hardware umdreht (als direkter Umschlag bezeichnet).

Eine noch leistungsfähigere Möglichkeit zum Anzeigen eines Geschenks wäre, dass Geschenke direkt vom Grafikkern angezeigt werden und der DWM vollständig umgangen wird. Diese Darstellungsmethode wird als independent flip (iflip) bezeichnet. Sowohl mehrschichtige als auch iflip werden unter Verwenden des DXGI-Flipmodells für optimale Leistung beschrieben.

Die Komposition ist die am einfachsten unterstützte, aber auch die am wenigsten effiziente. Die Oberfläche muss speziell zugeordnet werden, um für direkte Abscans oder Iflips geeignet zu sein, und diese Art der speziellen Zuordnung hat strengere Systemanforderungen als die Kompositions-Swapchain. Sie ist nur auf WDDM 3.0 und höherer Hardware verfügbar. Daher kann Ihre Anwendung die API-Unterstützung für die reine Kompositionspräsentation sowie die Präsentation abfragen, die für direktes Scannen oder Iflip qualifiziert ist.

Präsentationsfabrik, Überprüfungsfunktion und Präsentations-Manager

Das erste Objekt, das Ihre Anwendung aus der Kompositions-Swapchain-API verwendet, ist die Präsentationsfactory. Die Präsentationsfactory wird von Ihrer Anwendung erstellt und an ein Direct3D-Gerät gebunden, das Ihre Anwendung an den Aufruf zur Erstellung übergibt, und hat daher eine Affinität zu der grafikkarte, die diesem Gerät zugeordnet ist.

Die Präsentationsfactory macht Methoden verfügbar, um zu überprüfen, ob das aktuelle System und das aktuelle Grafikgerät in der Lage sind, die Kompositions-Swapchain-API zu verwenden. Sie können Funktionsmethoden wie IPresentationFactory::IsPresentationSupported verwenden, um die Systemunterstützung zu überprüfen. Wenn Funktionsmethoden die Systemunterstützung für die API angeben, können Sie die Präsentationsfactory verwenden, um einen Präsentations-Manager zu erstellen. Dieser Präsentations-Manager ist das Objekt, das Sie zum Ausführen von Präsentationsfunktionen verwenden, und ist an das gleiche Direct3D-Gerät und dieselbe Grafikkarte wie die Präsentationsfactory gebunden, die zum Erstellen verwendet wurde.

Derzeit sind die Systemanforderungen für die Verwendung der Composition-Swapchain-API überhaupt GPU-Treiber, die WDDM (Windows Device Driver Model) 2.0 und Windows 11 (Build 10.0.22000.194) oder höher unterstützen. Um die Kompositions-Swapchain-API auf die leistungsfähigste Weise zu verwenden (direktes Scannen und unabhängiges Flip oder Iflip), benötigen Systeme GPU-Treiber, die WDDM 3.0 unterstützen.

Wenn das System nicht in der Lage ist, die Kompositions-Swapchain-API zu verwenden, muss Ihre Anwendung über einen separaten Codepfad verfügen, um die Präsentation mit älteren Methoden zu behandeln, z. B. einer DXGI-Swapchain.

Registrieren von Präsentationspuffern für die Präsentation

Der Präsentations-Manager verfolgt Puffer nach, die er darstellen kann. Um eine Direct3D-Textur darzustellen, muss Ihre Anwendung diese Textur zuerst mit Direct3D erstellen und dann beim Präsentations-Manager registrieren. Wenn eine Textur beim Präsentations-Manager registriert wurde, wird sie als Präsentationspuffer bezeichnet und kann ab diesem Zeitpunkt von diesem Präsentationsmanager auf dem Bildschirm angezeigt werden. Ihre Anwendung kann Präsentationspuffer nach Belieben hinzufügen und entfernen, obwohl es eine maximale Anzahl von Präsentationspuffern gibt, die einem einzelnen Präsentations-Manager (derzeit 31) hinzugefügt werden können. Diese Präsentationspuffer können auch unterschiedliche Größen und Formate aufweisen, die bei der Darstellung eines einzelnen Präsentationspuffers wirksam werden.

Eine Textur kann bei einer beliebigen Anzahl von Präsentationsmanagern registriert werden. Dies wird jedoch in den meisten Fällen nicht als normale Verwendung betrachtet und führt zu komplizierten Synchronisierungsszenarien, für die Ihre Anwendung verantwortlich wäre.

Definieren des anzuzeigenden Inhalts

Im Allgemeinen müssen puffer, die wir präsentieren, Inhalten in einer visuellen Struktur zugeordnet werden. Aus diesem Grund müssen wir eine Art Bindung definieren, damit beim Auftreten von Anwendungsproblemen klar ist, wohin in der visuellen Struktur die angezeigten Puffer gehen sollen. Wir nennen diese Bindung Präsentationsinhalte.

Dargestellte Inhalte können viele Formen annehmen. Ihre Anwendung möchte möglicherweise einen einzelnen Puffer für die Anzeige oder Stereoinhalte mit Puffern für das linke und rechte Auge darstellen usw. Die erste Version dieser API bietet Unterstützung für die Darstellung eines einzelnen Puffers für den Bildschirm.

Wir definieren eine Präsentationsoberfläche als eine Form von Präsentationsinhalten, für die jeweils ein einzelner Puffer angezeigt wird. Eine Präsentationsoberfläche kann als Inhalt in einer visuellen Struktur festgelegt werden und gleichzeitig einen einzelnen Präsentationspuffer auf dem Bildschirm anzeigen. Präsentationen des Präsentations-Managers aktualisiert den Puffer, der von mindestens einer Präsentationsoberfläche atomar angezeigt wird.

Der Präsentations-Manager kann verwendet werden, um eine oder mehrere Präsentationsoberflächen für einen bestimmten Kompositionsoberflächengriff zu erstellen. Jedes Kompositionsoberflächenhandle kann an ein oder mehrere Visuals in einer visuellen Struktur gebunden werden (durch Strategien, die in der Dokumentation zur Windows.UI.Composition - und DirectComposition-API beschrieben sind), um die Beziehung zwischen der zugeordneten Präsentationsoberfläche und dem Ort zu definieren, an dem sie in ihrer visuellen Struktur angezeigt wird. Ihre Anwendung kann eine oder mehrere Präsentationsoberflächen aktualisieren, die an das System übermittelt werden und beim nächsten vorgang stattfinden.

Beachten Sie, dass der Präsentations-Manager einen beliebigen Präsentationspuffer für eine beliebige Anzahl von Präsentationsoberflächen bereitstellen kann. Es gibt keine Einschränkungen. Es liegt jedoch an Ihrer Anwendung, zu verfolgen, welche Puffer Sie ausgegeben haben und wo, um sicherzustellen, dass Sie nicht versuchen, eine neue Zeichnung für diesen Puffer auszugeben, während sie weiterhin von einer Präsentationsoberfläche angezeigt wird.

Anwenden von Eigenschaften auf die Präsentationsoberfläche

Neben der Angabe, welche Puffer in einer Präsentationsoberfläche angezeigt werden sollen, kann ein Geschenk auch verschiedene andere Eigenschaften für diese Präsentationsoberfläche angeben. Dazu gehören Eigenschaften, die definieren, wie die Quelltextur stichprobeniert wird, einschließlich des Alphamodus und des Farbraums, wie die Quelltextur transformiert und angelegt wird, sowie alle angezeigten oder Rückleseeinschränkungen für geschützte Inhalte. All diese Werden als Eigenschaftensettermethoden auf einer Präsentationsoberfläche verfügbar gemacht, die von Ihrer Anwendung geändert werden kann, und werden genau wie Pufferupdates wirksam, wenn die Anwendung vorhanden ist.

Präsentieren auf der Präsentationsoberfläche

Nachdem Ihre Anwendung Präsentationsoberflächen erstellt, Präsentationspuffer registriert und Aktualisierungen angibt, die während eines Geschenks auftreten sollen, können Sie diese Eigenschaften durch Präsentieren anwenden. Ihre Anwendung gibt ein Geschenk über den Präsentations-Manager aus. Wenn diese vom System verarbeitet wird, werden alle Updates atomar angewendet. Darüber hinaus kann Ihre Anwendung auch andere Eigenschaften der Gegenwart angeben, z. B. die ideale Zeit, die stattfinden soll (die aktuelle Zielzeit ) und andere seltenere Eigenschaften, z. B. die beabsichtigte Inhaltsrate, die verwendet werden können, um benutzerdefinierte Aktualisierungsmodi auf dem System zu aktivieren. Da Geschenke zu einem bestimmten Zeitpunkt geplant werden können, kann Ihre Anwendung mehrere Geschenke im Voraus ausgeben. Diese Geschenke werden nacheinander verarbeitet, wenn ihre geplante Zeit erreicht ist.

Synchronisieren der Präsentation

Ihre Anwendung muss sicher sein, dass sie beim Rendern in Puffern und auftretenden Problemen einen zu rendernden Puffer auswählt, auf den derzeit kein anderer ausstehender Früherer referenziert wird, da dies den puffernden Inhalt überschreiben könnte, den die Präsentationen beabsichtigten. Wenn Ihre Anwendung das Rendern in einem Puffer, der derzeit von einer Präsentationsoberfläche in Scanouthardware angezeigt wird, probleme hat, kann das Rendering auf unbestimmte Zeit verzögert werden, da Direct3D das Rendern des Frontpuffers nicht zuzulassen.

Die Kompositions-Swapchain-API bietet einige verschiedene Mechanismen, mit denen Ihre Anwendung die ordnungsgemäße Synchronisierung von Puffern üben kann, die sie präsentiert hat.

Es wird davon ausgesagt, dass ein Puffer verfügbar ist, wenn keine ausstehenden Geschenke vorhanden sind, die darauf verweisen, und er wird derzeit nicht vom System angezeigt. Andernfalls ist es nicht verfügbar. Die API stellt ein Ereignis für jeden Präsentationspuffer bereit, das angibt, ob der Puffer verfügbar ist. Dies ist die einfachste Methode der Synchronisierung für Ihre Anwendung. Bevor Sie in einen Puffer zeichnen und ihn darstellen, kann Ihre Anwendung sicherstellen, dass das verfügbare Ereignis signalisiert wird. Das für einen bestimmten Puffer verfügbare Ereignis wird in dem Moment, in dem es an eine Präsentationsoberfläche in der API gebunden wurde, nicht signalisiert und bleibt bis zur Einstellung der Gegenwart unsignalisiert.

Zweitens verfolgt der Präsentationsmanager einen einzelnen anwesenden, zurückgestellten Zaun , um mit Ihrer Anwendung zu kommunizieren, die abgeschlossen wurde. Der Wert des Zauns entspricht dem aktuellen Bezeichner des letzten Anwesenden, der mit der einstellungsbehafteten Phase seines Lebenszyklus begonnen hat, wie im abschnitt lebenszyklus unten erläutert. Sobald ein Geschenk in diese Phase eintritt, kann davon ausgegangen werden, dass alle Puffer, die durch nachfolgende Präsentationen ersetzt wurden, wiederverwendet werden können.

Diese Methode der Synchronisierung ist fortgeschrittener, ermöglicht jedoch eine größere Kontrolle über die Drosselung des Workflows und ist informativer über den Zustand des Systems in Bezug auf die Tiefe der aktuellen vorhandenen Warteschlange. Eine Übersicht über den Lebenszyklus eines Geschenks finden Sie im abschnitt unten.

Lebenszyklus eines Gegenwarts

Präsentations-Manager-Präsentationen werden im System als Teil der vorhandenen Warteschlange in die Warteschlange eingereiht. Die Systemprozesse werden in einer Warteschlange angezeigt. Darüber hinaus verfügt jedes Geschenk über einen eindeutigen (für den Präsentations-Manager) zugeordneten gegenwartsbezeichner, der ein inkrementierender Wert ist, der einem Geschenk zugewiesen ist, beginnend bei 1 für die erste Gegenwart und für jedes nachfolgende Geschenk um 1 erhöht wird. Dieser vorliegende Bezeichner wird in verschiedenen Teilen der API verwendet, z. B. Synchronisierungsgrundtypen und Präsentationsstatistiken, um auf diese bestimmte Gegenwart zu verweisen.

Bei jedem Vorhanden, bei dem Ihre Anwendungsprobleme auftreten, folgt ein bestimmter Lebenszyklus, wie hier beschrieben.

Sobald Ihre Anwendung die Änderungen eingerichtet hat, die als Teil eines Geschenks vorgenommen werden sollen, verwendet sie den Präsentations-Manager, um die Gegenwart tatsächlich auszugeben. An diesem Punkt soll die Gegenwart ausstehend sein.

Sobald ein Geschenk aussteht, befindet sich ein Geschenk in der aktuellen Warteschlange des Präsentationsmanagers, wo es bleibt, bis eines von zwei Dingen passiert.

• Die Gegenwart wird abgebrochen. Mit dem Präsentations-Manager kann Ihre Anwendung zuvor ausgestellte Geschenke abbrechen. Wenn dies geschieht, wird die Gegenwart als abgebrochen bezeichnet, und dann wird sie sofort außer Betrieb genommen. Bei diesem Übergang werden die zugeordneten verfügbaren Pufferereignisse für die abgebrochene Gegenwart aktualisiert, jedoch wird der aktuelle eingestellte Zaun nicht signalisiert, da die zuvor angezeigte Gegenwart (vor den abgebrochenen Geschenken) weiterhin angezeigt wird. Aus diesem Grund kann Ihre Anwendung den aktuellen Ausmusterungszaun nicht verwenden, um zu bestimmen, welche Geschenke abgebrochen wurden. Sie müssen dies stattdessen aus der aktuellen status Statistik lernen, die für jede abgebrochene Gegenwart zurückgegeben wird. Es wird empfohlen, dass Ihre Anwendung verfügbare Pufferereignisse verwendet, um einen verfügbaren Puffer zu finden, der nach einem Abbruch angezeigt werden soll. Sobald diese Gegenwart angezeigt wird, beginnt der vorherige Anwesende mit dem Ausmusterungsprozess und aktualisiert den aktuellen Ausmusterungszaun.
• Wenn sie nicht abgebrochen wird, ist die Gegenwart schließlich bereit für die Verarbeitung. Um bereit zu sein, müssen zwei Hauptvoraussetzungen erfüllt sein.
  • Alle Zeichnungsarbeiten, die vor dem Aufruf der Gegenwart an den Direct3D-Kontext ausgegeben wurden, müssen abgeschlossen werden. Dadurch wird sichergestellt, dass der Puffer nicht angezeigt wird, bevor die Zeichnung Ihrer Anwendung abgeschlossen ist.
  • Wenn eine aktuelle Zielzeit angegeben wurde, erfüllt die aktuelle systemrelative Zeit, von der wir erwarten, dass sie die Gegenwart anzeigen kann, die angeforderte Zielzeit, die Ihre Anwendung auf die Gegenwart angewendet hat.

Wenn das System entscheidet, ein Geschenk zu finden, das auf dem Bildschirm angezeigt werden soll, wählt es das letzte Geschenk aus, das für die Anzeige bereit ist. Wenn mehrere bereite Präsentationen vorhanden sind, werden alle außer der neuesten (d. h. die Gegenwart mit dem größten vorhandenen Bezeichner) übersprungen und treten sofort in den zustand außer Betrieb . An diesem Punkt werden die verfügbaren Pufferereignisse signalisiert, aber der aktuelle, auslaufende Zaun wird nicht signalisiert, da die übersprungene Gegenwart nicht vom angezeigten Zustand wechselt.

Wenn das bereite Geschenk für die Anzeige ausgewählt wird, beginnt das System mit der Arbeit, um es auf dem Bildschirm anzuzeigen. Dies kann bedeuten, dass der Puffer als Teil eines DWM-Frames gerendert wird und dann die Hardware angefordert wird, um diesen Frame auf dem Bildschirm anzuzeigen, oder es kann bedeuten, dass der Puffer im Fall von iflip direkt an die Scanout-Hardware gesendet wird. Danach soll die Gegenwart in die Warteschlange eingereiht werden. Auf hoher Ebene bedeutet dies, dass es auf dem Weg zur Anzeige ist.

Wenn die Hardware die Gegenwart anzeigt, soll diese Gegenwart angezeigt werden. Dort bleibt es auf dem Bildschirm sichtbar, bis ein nachfolgendes Geschenk eingeht und ersetzt es.

Wenn ein nachfolgendes Geschenk in die Warteschlange eingereiht wird, wissen wir, dass die Hardware schließlich die aktuelle Gegenwart nicht mehr anzeigt. An diesem Punkt wird gesagt, dass die Gegenwart in den Ruhestand geht.

Wenn diese nachfolgende Gegenwart angezeigt wird, wird die aktuelle Gegenwart als eingestellt bezeichnet.

Der Präsentations-Manager macht einen aktuellen, auslaufenden Zaun verfügbar, der dem aktuellen Bezeichner jedes Anwesenden signalisiert wird, wenn er in den status "Außerbetriebnahme " wechselt. Dieses Signal gibt Ihrer Anwendung an, dass es sicher geworden ist, Renderingarbeit in den puffern, die diesem zugeordnet sind, auszustellen, ohne ein vorheriges Vorhanden zu beschädigen. Wenn Ihre Anwendung während des aktuellen Einstellungszustands Renderingarbeitsprobleme hat, wird die Renderingarbeit in die Warteschlange eingereiht, bis die aktuelle in den eingestellten Zustand wechselt und an diesem Punkt ausgeführt wird. Wenn die Renderingarbeit ausgegeben wird, nachdem die vorhandene außer Betrieb genommen wurde, wird sie sofort ausgeführt.

Im Folgenden ist ein Diagramm dieser Zustandsänderung dargestellt.

Diagramm von Puffern, Oberflächen und Darstellungen

Im Folgenden finden Sie ein Diagramm zum Präsentations-Manager, zu Präsentationspuffern, Präsentationsoberflächen, Präsentationen und Updates.

Dieses Diagramm zeigt einen Präsentations-Manager mit zwei Präsentationsoberflächen und drei Präsentationspuffern, für die bisher zwei ausgestellte Geschenke ausgestellt wurden – der erste vorliegende pufferte 1 in Surface 1 und puffer 2 in Surface 2. Der zweite vorliegende Hat Surface 2 aktualisiert, um den Präsentationspuffer 3 anzuzeigen, und die Bindung von Surface 1 wurde nicht geändert. Nachdem die aktuelle 2 angezeigt wurde, zeigt Surface 1 puffer 1 und Surface 2 den Puffer 3 an, der im aktuellen Zustand der Objekte im Präsentations-Manager zu sehen ist. Alle in der Warteschlange vorhandenen Elemente werden wirksam, wenn sie im System verarbeitet werden.

Hinweis

Da Present 2 den Puffer für Surface 1 nicht geändert hat, wurde Surface 1 von der vorherigen Gegenwart an Puffer 1 gebunden. In diesem Sinne gibt es einen "impliziten" Verweis auf Puffer 1 in der aktuellen Version 2, da Oberfläche 1 an Puffer 1 gebunden bleibt, nachdem die aktuelle 2 angezeigt wurde.

Hinzufügen von Präsentationsoberflächen zur visuellen Struktur

Präsentationsoberflächen sind Inhalte, die als Teil einer visuellen Kompositionsstruktur vorhanden sind. Jede Präsentationsoberfläche ist an einen Ziehpunkt für die Kompositionsoberfläche gebunden. In Windows.UI.Composition kann ein Oberflächenpinsel für einen bereits vorhandenen Kompositionsoberflächenziehpunkt erstellt und an ein Sprite-Visual gebunden werden. In DirectComposition kann eine Kompositionsoberfläche aus einem bereits vorhandenen Kompositionsoberflächenziehpunkt erstellt und als Inhalt an ein Visual gebunden werden. Weitere Informationen finden Sie in der jeweiligen Dokumentation für jede API.

APIs wie Windows Media Foundation, die für die Verwendung dieser API entwickelt wurden, machen Kompositionsoberflächenhandles verfügbar, die vorab an eine Präsentationsoberfläche gebunden werden. Eine Anwendung kann auch einen eigenen Ziehpunkt für die Kompositionsoberfläche erstellen, um anschließend an eine Präsentationsoberfläche zu binden und durch Aufrufen von DCompositionCreateSurfaceHandle zu einer visuellen Struktur hinzuzufügen.

Lesen von Präsentationsstatistiken

Die Kompositions-Swapchain-API macht Präsentationsstatistiken verfügbar, die verschiedene Informationen darüber beschreibt, wie eine bestimmte Gegenwart verarbeitet wurde. Die Informationen können im Allgemeinen beschreiben, wie eine Präsentationsoberfläche in einem DWM-Frame verwendet wurde, zu welchem Zeitpunkt sie angezeigt wurde, ob sie überhaupt angezeigt wurde usw.

Es gibt verschiedene Arten von Präsentationsstatistiken, die in zukünftigen Versionen der API erweiterbar sind. Eine Anwendung verwendet den Präsentations-Manager, um sich zu registrieren, um typen von Statistiken zu erhalten, an der sie interessiert ist. Diese Statistiken werden dann in die Statistikwarteschlange des Präsentations-Managers gepusht. Der Präsentations-Manager macht ein verfügbares Statistikereignis für Anwendungen verfügbar. Hierbei handelt es sich um ein Ereignishandle, das angibt, wann die Statistikwarteschlange Statistikelemente zum Lesen enthält. Wenn dies der Fall ist, kann Ihre Anwendung das erste Statistikelement aus der Warteschlange entfernen, es lesen und verarbeiten. Der Präsentations-Manager setzt das Ereignis "Statistiken verfügbar" zurück, wenn Ihre Anwendung alle Statistiken gelesen hat, die sich derzeit in der Warteschlange befinden. In der Regel liest und verarbeitet eine Anwendung Statistiken in einer Schleife, bis das Ereignis für die verfügbare Statistik zurückgesetzt wurde. Es wird üblich sein, dass Ihre Anwendung diese Statistikwarteschlange in derselben Arbeitsschleife verarbeitet, die Sie zum Ausgeben von Geschenken verwenden. Das vorgeschlagene Verwendungsmuster besteht darin, die Verarbeitung von Statistiken gegenüber der Ausgabe neuer Geschenke zu priorisieren, um sicherzustellen, dass die Warteschlange nicht überläuft.

Die Warteschlange verfügt über eine maximale Anzahl von Statistiken, die nachverfolgt werden, und zwar in der Reihenfolge von 512 bis 1024 Statistiken. Die maximale Warteschlangentiefe sollte ausreichen, um statistiken im Normalfall von ca. 5 Sekunden zu speichern. Wenn die Statistikwarteschlange voll wird und mehr Statistiken gemeldet werden, wird die älteste Statistik eingestellt, um Platz zu schaffen.

Zugehörige Themen

• Kompositions-Swapchain
• Verwenden Sie das DXGI-Flip-Modell, um eine optimale Leistung zu erzielen.