comportement Windowed-Mode

Le runtime Microsoft Direct3D pour un appareil en mode fenêtré n’appelle jamais les fonctions d’un pilote d’affichage en mode utilisateur pour verrouiller une surface principale pivotée, pour effectuer un rendu vers une surface principale pivotée ou pour effectuer des transferts de blocs de bits (bitblt) vers ou à partir d’une surface principale pivotée. Autrement dit, le runtime Direct3D d’un appareil en mode fenêtré gère toutes ces situations.

Le runtime Direct3D pour un appareil en mode fenêtré peut ne pas appeler la fonction OpenResource du pilote d’affichage en mode utilisateur pour ouvrir la surface principale partagée et informer le pilote d’affichage en mode utilisateur de l’orientation de la surface principale. Toutefois, si le gestionnaire de fenêtres de bureau (DWM) n’est pas en cours d’exécution, le runtime Direct3D appelle OpenResource et le pilote d’affichage en mode utilisateur est informé de l’orientation du serveur principal. Le pilote d’affichage en mode utilisateur doit être conscient de l’orientation de la surface principale uniquement si le pilote doit accéder à la surface principale (via un bitblt ou un verrou) à ses propres fins ; le runtime Direct3D pour un appareil en mode fenêtré ne demande jamais au pilote d’affichage en mode utilisateur d’accéder à une surface principale pivotée. Par conséquent, si le pilote d’affichage en mode utilisateur doit accéder à la surface principale à ses propres fins internes, le pilote nécessite un mécanisme en plus d’un appel à sa fonction OpenResource , car OpenResource n’est pas toujours appelé.

La fonction DWM ou d’affichage du pilote miniport DxgkDdiPresent fait pivoter les données en mode fenêtré.