Partager via


Considérations relatives aux performances et bonnes pratiques

Cette rubrique présente un ensemble de bonnes pratiques pour l’utilisation des API Desktop Window Manager (DWM).

Cette rubrique contient les sections suivantes :

Pratiques d’application pour DWM

Si votre application gère la mise à l’échelle des points par pouce (ppp), vous pouvez déclarer une application comme prenant en charge les ppp et empêcher la mise à l’échelle automatique en définissant l’indicateur de prise en charge des ppp dans le manifeste du programme ou en appelant la fonction SetProcessDPIAware pendant l’initialisation du programme.

Une fois la composition DWM activée, les applications masquées ne reçoivent plus de messages WM_PAINT et ne sont pas invitées à effectuer un nouveau rendu. Le contenu de chaque fenêtre est déjà disponible pour composer l’image d’écran.

Les fenêtres de WS_EX_TRANSPARENT de niveau supérieur doivent être combinées avec un style WS_EX_LAYERED à des fins de test d’accès. WS_EX_TRANSPARENT au sens classique, sans redirection, est utile pour les fenêtres enfants dans une hiérarchie de fenêtres qui appartiennent au même thread, mais qui ne sont pas destinées aux fenêtres de niveau supérieur.

Utilisez des régions ou des superpositions pour créer des fenêtres en forme ou fusionnées. Notez que dans Windows Vista et les versions ultérieures de Windows, le dessin personnalisé uniquement une partie d’une fenêtre de niveau supérieur ne fournit pas le contenu obsolète souhaité dans les régions non retirées.

Les API telles que GetDCOrgEx peuvent être utilisées pour déterminer certaines valeurs réelles. Si vous avez un contexte d’appareil (DC) pour une fenêtre redirigée, l’origine retournée par GetDCOrgEx ne correspond pas à l’origine de votre fenêtre à l’écran. L’origine sera plutôt l’origine de la surface d’arrière-mémoire tampon pour votre fenêtre : (0, 0).

Lorsque tout le reste échoue, désactivez le rendu de fenêtre en appelant la fonction DwmSetWindowAttribute .

Pratiques de dessin pour DWM

Évitez de dessiner directement sur l’aire d’affichage principale. Cela force le DWM à désactiver la composition jusqu’à ce que votre application libère la surface principale de l’appareil.

Évaluez si votre application doit fournir sa propre double mise en mémoire tampon. Le DWM double le contenu de la mémoire tampon et présente la fenêtre dans un cadre unique.

Évitez de lire ou d’écrire dans un contrôleur de domaine d’affichage. Bien que pris en charge par DWM, nous ne le recommandons pas en raison de performances réduites.

Évitez de dessiner dans la zone non cliente. Bien que cette zone soit accessible par l’application et que le dessin soit pris en charge par l’API Microsoft Win32, cela peut entraîner la perte de toute bordure en verre dans la fenêtre.

Évitez de mélanger Windows Graphics Device Interface (GDI) et Microsoft DirectX, sauf s’ils ne se chevauchent pas. Si la combinaison est nécessaire, dessinez le contenu GDI dans une surface logicielle DirectX et combinez-les avant de les composer à l’écran, ou bien dessinez-les dans des fenêtres distinctes.

Utilisez la fonction BitBlt ou StretchBlt au lieu de Windows GDI+ pour présenter votre dessin à des fins de rendu. GDI+ affiche une ligne de balayage à la fois avec un rendu logiciel. Cela peut entraîner un scintillement dans vos applications.

Région du client DWM Blur-Behind

Le rendu de l’effet de flou est une opération gourmande en ressources pour le processeur et l’unité de traitement graphique (GPU). Les développeurs d’applications sont invités à prendre en compte les implications de l’utilisation du flou de zone client afin qu’il ne consomme pas trop de ressources. Vous devez être particulièrement prudent dans les cas suivants :

  • Lorsque vous vous attendez à ce que la taille du flou de zone client soit significative, même si aucune mise à jour ne se produit dans la zone floue elle-même. Le flou doit être affiché au cas où des mises à jour se produisent dans la zone floue de la fenêtre, ce qui entraîne des coûts de processeur et de GPU. En outre, les opérations de fenêtre sur la fenêtre (déplacement/redimensionnement/transitions) entraînent des coûts plus élevés.
  • Quand vous attendez des mises à jour significatives dans la zone cliente floue. Cela nécessite une repeint du flou à chaque mise à jour et consomme des ressources excessives.
  • Si le flou devrait couvrir une zone importante et que des mises à jour de cette zone sont également attendues, nous vous recommandons vivement de ne pas flouter la zone cliente.