Architecture et composants

Cette rubrique décrit les composants qui composent Microsoft DirectComposition. Il se compose des sections suivantes.

• Composants logiciels
• Bibliothèque d’applications
• Moteur de composition
• Rubriques connexes

Composants logiciels

DirectComposition se compose des composants logiciels main suivants.

• Bibliothèque d’applications en mode utilisateur (dcomp.dll) qui implémente l’API publique com (Component Object Model).
• Un moteur de composition en mode utilisateur (dwmcore.dll) hébergé dans le processus Desktop Window Manager (DWM) (dwm.exe) et effectue la composition réelle du bureau.
• Base de données d’objets en mode noyau (partie de win32k.sys) qui marshale les commandes de l’application vers le moteur de composition.

Une seule instance du moteur de composition gère les arborescences de composition DirectComposition pour toutes les applications et l’arborescence de composition DWM, qui représente l’ensemble du bureau. La base de données d’objets en mode noyau et le moteur de composition en mode utilisateur sont instanciés une fois par session, de sorte qu’un ordinateur Terminal Server avec plusieurs utilisateurs dispose de plusieurs instances de ces deux composants.

Le diagramme suivant montre les main composants DirectComposition et leur relation entre eux.

Bibliothèque d’applications

La bibliothèque d’applications DirectComposition est une API COM publique avec un point d’entrée plat unique qui est exporté à partir de dcomp.dll et retourne un pointeur d’interface vers un objet d’appareil. L’objet d’appareil, à son tour, a des méthodes pour créer tous les autres objets, chacun d’eux étant représenté par un pointeur d’interface. Toutes les interfaces DirectComposition héritent de et implémentent entièrement l’interface IUnknown . Toutes les méthodes qui acceptent les interfaces DirectComposition case activée si l’interface est implémentée à l’intérieur de dcomp.dll ou si elle est implémentée par un autre composant. Étant donné que DirectComposition n’est pas extensible, les méthodes qui prennent des interfaces comme paramètres retournent E_INVALIDARG si les interfaces ne sont pas implémentées dans dcomp.dll. L’API ne nécessite aucun privilège spécial ; Il peut être appelé par des processus s’exécutant au niveau d’accès le plus bas. Toutefois, étant donné que l’API ne fonctionne pas dans la session 0, elle ne convient pas aux services. À cet égard, l’API DirectComposition est similaire à d’autres API Microsoft DirectX, notamment Direct2D, Microsoft Direct3D et Microsoft DirectWrite.

Étant donné que le moteur de composition est conçu exclusivement pour l’exécution asynchrone, les propriétés d’objet dans l’API DirectComposition sont en écriture seule. Toutes les propriétés ont des méthodes setter, mais pas des méthodes getter. La lecture des propriétés n’est pas seulement gourmande en ressources, mais peut également être inexacte, car toute valeur retournée par le moteur de composition peut immédiatement devenir non valide. Cela peut se produire si, par exemple, une animation indépendante est liée à la propriété en cours de lecture.

L’API est thread-safe. Une application peut appeler n’importe quelle méthode à partir de n’importe quel thread à tout moment. Toutefois, étant donné que de nombreuses méthodes d’API doivent être appelées dans une séquence particulière, sans aucune synchronisation, une application peut subir un comportement imprévisible en fonction de la façon dont les threads s’entrelacent. Par exemple, si deux threads modifient la même propriété du même objet en valeurs différentes en même temps, l’application ne peut pas prédire laquelle des deux valeurs sera la valeur finale de la propriété. De même, si deux threads appellent Commit sur le même appareil, aucun des threads n’obtient un comportement transactionnel, car un appel à Commit sur un thread envoie le lot de toutes les commandes émises par les deux threads, pas seulement par celui qui a appelé Commit.

Le système conserve tout l’état interne par objet d’appareil. Si une application crée au moins deux objets d’appareil DirectComposition, l’application peut conserver des lots indépendants et d’autres états entre les deux.

Tous les objets DirectComposition ont une affinité d’objet d’appareil ; Les objets créés par un objet d’appareil particulier peuvent être utilisés uniquement avec cet objet d’appareil et peuvent être associés uniquement à d’autres objets créés par le même objet d’appareil. En d’autres termes, chaque objet d’appareil est un îlot disjoint de fonctionnalités distinct. La seule exception est la classe visuelle, qui permet de créer des arborescences visuelles où un visuel peut appartenir à un objet d’appareil différent de son parent. Cela permet des scénarios dans lesquels une application et un contrôle peuvent gérer une arborescence de composition unique sans avoir à partager un seul objet d’appareil DirectComposition.

Moteur de composition

Le moteur de composition DirectComposition s’exécute sur un processus dédié, distinct de tout processus d’application. Un processus de composition unique, dwm.exe, prend en charge chaque application d’une session. Chaque application peut créer deux arborescences visuelles pour chaque fenêtre dont elle est propriétaire. Toutes les arborescences sont en fait implémentées en tant que sous-arborescences d’une arborescence visuelle plus grande qui englobe également les structures de composition de DWM. Le DWM construit une grande arborescence visuelle pour chaque bureau dans une session. Voici les principaux avantages de cette architecture :

• Le moteur de composition a accès à toutes les bitmaps d’application et les arborescences visuelles, ce qui permet l’interopérabilité et la composition des fenêtres interprocessus.
• Le moteur de composition s’exécute dans un processus système approuvé distinct de tout processus d’application, ce qui permet aux applications disposant de droits d’accès faibles de composer du contenu protégé de manière sécurisée.
• Le moteur de composition peut détecter quand une fenêtre particulière est entièrement obclée et éviter de gaspiller les ressources processeur et gpu (PROCESSEUR) composant pour la fenêtre.
• Le moteur de composition peut composer directement dans la mémoire tampon arrière de l’écran, ce qui évite d’avoir besoin d’une copie supplémentaire requise pour les moteurs de composition par processus.
• Toutes les applications partagent un seul appareil Direct3D pour la composition, ce qui offre des économies de mémoire considérables

L’arborescence visuelle est une structure conservée. L’API DirectComposition expose des méthodes pour modifier la structure dans des lots de modifications qui sont traitées atomiquement. L’objet racine dans l’API DirectComposition est l’objet device, qui sert de fabrique pour tous les autres objets DirectComposition et contient une méthode appelée Commit. Le moteur de composition ne reflète pas les modifications apportées par l’application à l’arborescence visuelle jusqu’à ce que l’application appelle Commit, auquel cas toutes les modifications depuis la dernière validation sont traitées en tant que transaction unique.

L’exigence d’appeler Commit est similaire au concept de « frame », sauf que, étant donné que le moteur de composition s’exécute de manière asynchrone, il peut présenter plusieurs trames différentes entre les appels à Commit. Dans DirectComposition, un frame est une itération unique du moteur de composition, et l’intervalle passé par une application entre deux appels à Commit est appelé un lot.

DirectComposition traite par lot tous les appels d’application à l’API DirectComposition. La base de données d’objets du noyau, qui est implémentée dans le pilote de session win32k.sys, stocke toutes les informations d’état associées aux appels d’API.

Le moteur de composition produit un cadre pour chaque vide vertical dans l’affichage. Le cadre est démarré à un vide vertical et cible le vide vertical suivant. Lorsque le frame démarre, le moteur de composition récupère tous les lots en attente et inclut leurs commandes dans ce frame. Les lots sont placés dans une file d’attente en attente lorsque l’application appelle Commit, et la file d’attente en attente est vidée atomiquement au début du frame. Par conséquent, il existe un seul point dans le temps qui marque le début d’une trame. Tous les lots envoyés avant ce point sont inclus dans le frame, tandis que tous les lots envoyés après doivent attendre que la trame suivante soit traitée. La boucle de composition complète est la suivante :

1. Estimez l’heure du vide vertical suivant.
2. Récupérez tous les lots en attente.
3. Traitez les lots récupérés.
4. Mettez à jour toutes les animations en utilisant le temps estimé à l’étape 1.
5. Déterminez les régions de l’écran qui doivent être re-composées.
6. Composez de nouveau les régions sale.
7. Présentez le cadre en retournant les mémoires tampons d’arrière et d’avant pour chaque écran.
8. Si rien n’a été composé et présenté aux étapes 6 et 7, attendez qu’un lot soit validé.
9. Attendez le vide vertical suivant.

S’il existe plusieurs moniteurs attachés à une seule carte vidéo, le moteur de composition utilise l’espace vertical du moniteur principal pour piloter la boucle de composition et définir les durées d’échantillonnage de l’animation. Chaque moniteur est représenté par une chaîne de retournement en plein écran distincte ; le moteur de composition répète les étapes 6 et 7 pour chaque moniteur, de façon à ce que le tourniquet soit utilisé à l’aide d’un seul appareil Direct3D. S’il existe également plusieurs cartes vidéo, le moteur de composition utilise un appareil Direct3D distinct pour chaque carte vidéo aux étapes 6 et 7.

Les cadres de composition sont planifiés pour toujours démarrer à un vide vertical, comme le montre l’illustration suivante.

Si le moteur de composition n’a pas de travail à effectuer, car l’arborescence de composition n’a pas changé, le thread de composition se met en veille pendant l’attente d’un nouveau lot. Lorsqu’un nouveau lot est envoyé, le thread de composition se réveille mais revient immédiatement en veille jusqu’au vide vertical suivant. Ce comportement garantit des heures de début et de fin d’images prévisibles pour les applications et pour le moteur de composition.

Le moteur de composition publie les heures de présentation des images et la fréquence d’images actuelle. La publication de ces informations permet aux applications d’estimer la durée de présentation de leurs propres lots, ce qui permet de synchroniser les animations. En particulier, une application peut utiliser une combinaison de statistiques d’images du moteur de composition et un modèle historique de la durée nécessaire à son thread d’interface utilisateur pour produire un lot, afin de déterminer le temps d’échantillonnage de ses propres animations.

Par exemple, au début du lot d’application illustré dans l’illustration précédente, l’application peut interroger le moteur de composition pour déterminer l’heure de présentation exacte de l’image suivante. L’application peut ensuite utiliser l’heure actuelle, ainsi que des informations sur les lots précédents qu’elle a produits, pour déterminer si l’application peut terminer le lot actuel avant le vide vertical suivant. Par conséquent, l’application utilise le temps de présentation de l’image comme heure d’échantillonnage pour ses propres animations. Si l’application détermine qu’il est peu probable qu’elle termine son travail dans le vide vertical actuel, l’application peut utiliser l’heure d’exécution suivante comme heure d’échantillonnage à la place, en utilisant les informations de fréquence d’images retournées par le moteur de composition pour calculer cette heure.

Rubriques connexes

DirectComposition Concepts