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 principaux composants logiciels suivants.

• Bibliothèque d’applications en mode utilisateur (dcomp.dll) qui implémente l’API publique com (Component Object Model).
• Moteur de composition en mode utilisateur (dwmcore.dll) hébergé dans le processus du Gestionnaire de fenêtres de bureau (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’intégralité du bureau. La base de données d’objets en mode noyau et le moteur de composition en mode utilisateur sont instanciées une fois par session. Par conséquent, un ordinateur Terminal Server avec plusieurs utilisateurs a plusieurs instances de ces deux composants.

Le diagramme suivant montre les principaux composants DirectComposition et la façon dont ils se rapportent les uns aux autres.

Bibliothèque d’applications

La bibliothèque d’applications DirectComposition est une API COM publique avec un point d’entrée plat unique 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 et implémentent entièrement l’interface IUnknown. Toutes les méthodes qui acceptent les interfaces DirectComposition vérifient 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 en tant que 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 de l’API DirectComposition sont en écriture seule. Toutes les propriétés ont des méthodes setter, mais pas des méthodes getter. Les propriétés de lecture ne sont pas seulement gourmandes en ressources, mais peuvent également être inexactes, 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 synchronisation, une application peut rencontrer un comportement imprévisible en fonction de la façon dont les threads 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 quelle 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 thread n’obtient réellement le comportement transactionnel, car un appel à Commit sur un thread envoie le lot de toutes les commandes émises par les deux threads, pas seulement celle appelée Commit.

Le système gère l’état interne par objet d’appareil. Si une application crée deux objets d’appareil DirectComposition ou plus, l’application peut conserver des lots indépendants et un autre état 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 ne peuvent être associés qu’à d’autres objets créés par le même objet d’appareil. En d’autres termes, chaque objet d’appareil est une île disjointe de fonctionnalités distincte. L’une des exceptions est la classe visuelle, qui permet la création d’arborescences visuelles où un visuel peut appartenir à un objet d’appareil différent de son parent. Cela permet des scénarios où une application et un contrôle peuvent gérer une arborescence de composition unique sans avoir également besoin de 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 dans une session. Chaque application peut créer deux arborescences visuelles pour chaque fenêtre qu’elle possède. Tous les arbres sont réellement implémentés en tant que sous-arborescences d’une arborescence visuelle plus grande qui englobe également les structures de composition de DWM. Le DWM construit une arborescence visuelle volumineuse pour chaque bureau dans une session. Voici les principaux avantages de cette architecture :

• Le moteur de composition a accès à toutes les bitmaps et arborescences visuelles de l’application, ce qui permet l’interopérabilité et la composition entre les fenêtres interprocesseurs.
• 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 faible pour composer en toute sécurité du contenu protégé.
• Le moteur de composition peut détecter lorsqu’une fenêtre particulière est entièrement obstruée et éviter de perdre des ressources processeur et processeur (GPU) composées 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 par lots de modifications traitées atomiquement. L’objet racine de l’API DirectComposition est l’objet d’appareil, 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 tant que l’application n’appelle validation, auquel cas toutes les modifications apportées depuis la dernière Validation sont traitées en tant que transaction unique.

L’exigence d’appeler validation est similaire au concept d’une « trame », 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é de lot.

DirectComposition traite tous les appels d’application à l’API DirectComposition. La base de données d’objets noyau, 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. Au démarrage de l’image, 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 Commitet que la file d’attente en attente est vidée atomiquement au début de l’image. Par conséquent, il existe un point unique dans le temps qui marque le début d’une trame. Tous les lots envoyés avant ce point sont inclus dans l’image, tandis que tous les lots envoyés après doivent attendre que l’image suivante soit traitée. La boucle de composition complète est la suivante :

1. Estimer 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 à l’aide du temps estimé à l’étape 1.
5. Déterminez les régions de l’écran qui doivent être réécrites.
6. Réinscrire les régions sales.
7. Présentez le cadre en retournant les mémoires tampons arrière et 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 l’espace vertical suivant.

S’il existe plusieurs moniteurs attachés à une seule carte vidéo, le moteur de composition utilise le vide vertical du moniteur principal pour piloter la boucle de composition et définir les heures d’échantillonnage d’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 manière tourniquet, à l’aide d’un seul appareil Direct3D. S’il existe également plusieurs adaptateurs vidéo, le moteur de composition utilise un appareil Direct3D distinct pour chaque carte vidéo aux étapes 6 et 7.

Les trames de composition sont planifiées pour toujours commencer à un vide vertical, comme l’illustre l’illustration suivante.

Si le moteur de composition n’a pas de travail à faire car l’arborescence de composition n’a pas changé, le thread de composition se met en veille en attendant un nouveau lot. Lorsqu’un nouveau lot est envoyé, le thread de composition s’éveille, mais revient immédiatement en veille jusqu’à ce que le prochain champ vertical soit vide. 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 d’images et la fréquence d’images actuelle. La publication de ces informations permet aux applications d’estimer le temps de présentation de leurs propres lots, ce qui permet à leur tour de synchroniser les animations. En particulier, une application peut utiliser une combinaison de statistiques d’images à partir du moteur de composition et d’un modèle historique de la durée pendant laquelle son thread d’interface utilisateur prend pour produire un lot, afin de déterminer le temps d’échantillonnage de ses propres animations.

Par exemple, au début du lot d’applications indiqué 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 temps d’échantillonnage pour ses propres animations. Si l’application détermine qu’il est peu probable d’effectuer son travail dans le vide vertical actuel, l’application peut utiliser le temps d’intervalle suivant comme heure d’échantillonnage à la place, à l’aide des informations de fréquence d’images retournées par le moteur de composition pour calculer cette heure.

Rubriques connexes

concepts DirectComposition