Vue d’ensemble de DXGI

Microsoft DirectX Graphics Infrastructure (DXGI) reconnaît que certaines parties des graphiques évoluent plus lentement que d’autres. L’objectif principal de DXGI est de gérer des tâches de bas niveau qui peuvent être indépendantes du runtime graphique DirectX. DXGI fournit une infrastructure commune pour les futurs composants graphiques ; le premier composant qui tire parti de DXGI est Microsoft Direct3D 10.

Dans les versions précédentes de Direct3D, des tâches de bas niveau telles que l’énumération des périphériques matériels, la présentation des images rendues à une sortie, le contrôle de gamma et la gestion d’une transition en plein écran ont été incluses dans le runtime Direct3D. Ces tâches sont désormais implémentées dans DXGI.

L’objectif de DXGI est de communiquer avec le pilote en mode noyau et le matériel système, comme illustré dans le diagramme suivant.

Une application peut accéder directement à DXGI ou appeler les API Direct3D dans D3D11_1.h, D3D11.h, D3D10_1.h ou D3D10.h, qui gère les communications avec DXGI pour vous. Vous pouvez utiliser DXGI directement si votre application doit énumérer des appareils ou contrôler la façon dont les données sont présentées à une sortie.

Cette rubrique contient les sections suivantes.

• Énumération des adaptateurs
  • Nouvelles informations sur l’énumération des adaptateurs pour Windows 8
• Présentation
  • Créer une chaîne d’échange
  • Gestion et alimentation de la chaîne d’échange
  • Gestion du redimensionnement des fenêtres
  • Choix de la sortie et de la taille DXGI
  • Débogage en mode Full-Screen
  • Destruction d’une chaîne d’échange
  • Utilisation d’un moniteur pivoté
  • Changement de modes
  • Conseil de performances en mode plein écran
  • Considérations sur les multithreads
• Réponses DXGI de DLLMain
• Modifications de DXGI 1.1
• Modifications de DXGI 1.2
• rubriques connexes

Pour voir quels formats sont pris en charge par le matériel Direct3D 11 :

• Prise en charge du format DXGI pour le matériel Direct3D 12.1
• Prise en charge du format DXGI pour le matériel Direct3D, niveau de fonctionnalité 12.0
• Prise en charge du format DXGI pour le matériel de niveau fonctionnel Direct3D 11.1
• Prise en charge du format DXGI pour le matériel de niveau de fonctionnalité Direct3D 11.0
• Prise en charge matérielle des formats Direct3D 10Level9
• Prise en charge matérielle des formats Direct3D 10.1
• Prise en charge matérielle des formats Direct3D 10

Énumération des adaptateurs

Un adaptateur est une abstraction du matériel et de la capacité logicielle de votre ordinateur. Il existe généralement de nombreux adaptateurs sur votre machine. Certains appareils sont implémentés dans du matériel (comme votre carte vidéo) et certains sont implémentés dans des logiciels (comme le ratériseur de référence Direct3D). Les adaptateurs implémentent les fonctionnalités utilisées par une application graphique. Le diagramme suivant montre un système avec un seul ordinateur, deux adaptateurs (cartes vidéo) et trois moniteurs de sortie.

Lors de l’énumération de ces éléments matériels, DXGI crée une interface IDXGIOutput1 pour chaque sortie (ou moniteur) et une interface IDXGIAdapter2 pour chaque carte vidéo (même s’il s’agit d’une carte vidéo intégrée à une carte mère). L’énumération est effectuée à l’aide d’un appel d’interface IDXGIFactory, IDXGIFactory ::EnumAdapters, pour retourner un ensemble d’interfaces IDXGIAdapter qui représentent le matériel vidéo.

DXGI 1.1 a ajouté l’interface IDXGIFactory1 . IDXGIFactory1 ::EnumAdapters1 retourne un ensemble d’interfaces IDXGIAdapter1 qui représentent le matériel vidéo.

Si vous souhaitez sélectionner des fonctionnalités de matériel vidéo spécifiques lorsque vous utilisez des API Direct3D, nous vous recommandons d’appeler de manière itérative la fonction D3D11CreateDevice ou D3D11CreateDeviceAndSwapChain avec chaque handle d’adaptateur et le niveau de fonctionnalité matériel possible. Cette fonction réussit si le niveau de fonctionnalité est pris en charge par l’adaptateur spécifié.

Nouvelles informations sur l’énumération des adaptateurs pour Windows 8

À compter de Windows 8, un adaptateur appelé « Microsoft Basic Render Driver » est toujours présent. Cet adaptateur a un VendorId de 0x1414 et un DeviceID de 0x8c. Cet adaptateur a également la valeur DXGI_ADAPTER_FLAG_SOFTWARE définie dans le membre Indicateurs de sa structure DXGI_ADAPTER_DESC2 . Cet adaptateur est un appareil de rendu uniquement qui n’a pas de sorties d’affichage. DXGI ne retourne jamais DXGI_ERROR_DEVICE_REMOVED pour cet adaptateur.

Si le pilote d’affichage d’un ordinateur ne fonctionne pas ou est désactivé, l’adaptateur principal (NULL) de l’ordinateur peut également être appelé « Pilote de rendu Microsoft Basic ». Toutefois, cet adaptateur a des sorties et n’a pas la valeur DXGI_ADAPTER_FLAG_SOFTWARE définie. Le système d’exploitation et les applications utilisent cet adaptateur par défaut. Si un pilote d'affichage est installé ou activé, les applications peuvent recevoir DXGI_ERROR_DEVICE_REMOVED pour cet adaptateur, puis doivent réenumérer les adaptateurs.

Lorsque l’adaptateur d’affichage principal d’un ordinateur est l'« adaptateur d’affichage de base Microsoft » (adaptateur WARP ), cet ordinateur dispose également d’un deuxième adaptateur. Ce deuxième adaptateur est un dispositif uniquement dédié au rendu qui n'a aucune sortie d'écran, et pour lequel DXGI ne retourne jamais DXGI_ERROR_DEVICE_REMOVED.

Si vous souhaitez utiliser WARP pour le rendu, le calcul ou d’autres tâches longues, nous vous recommandons d’utiliser l’appareil de rendu uniquement. Vous pouvez obtenir un pointeur vers l’appareil render uniquement en appelant la méthode IDXGIFactory1 ::EnumAdapters1 . Vous créez également le périphérique de rendu uniquement lorsque vous spécifiez D3D_DRIVER_TYPE_WARP dans le paramètre DriverType de D3D11CreateDevice , car l’appareil WARP utilise également l’adaptateur WARP de rendu uniquement.

Présentation

Le travail de votre application consiste à afficher des images et à demander à DXGI de présenter ces images à la sortie. Si l'application dispose de deux mémoires tampons disponibles, elle peut en rendre une tout en présentant l'autre. L’application peut nécessiter plus de deux mémoires tampons en fonction du temps nécessaire pour afficher une image ou la fréquence d’images souhaitée pour la présentation. L’ensemble de mémoires tampons créées est appelé chaîne d’échange, comme indiqué ici.

• Créer une chaîne d’échange
• Gestion et alimentation de la chaîne d’échange
• Gestion du redimensionnement des fenêtres
• Choix de la sortie et de la taille DXGI
• Débogage en mode Full-Screen
• Destruction d’une chaîne d’échange
• Utilisation d’un moniteur pivoté
• Changement de modes
• Conseil de performances en mode plein écran
• Considérations sur les multithreads

Une chaîne d’échange a une mémoire tampon frontale et une ou plusieurs mémoires tampons d’arrière-plan. Chaque application crée sa propre chaîne d’échange. Pour optimiser la vitesse de présentation des données vers une sortie, une chaîne d’échange est presque toujours créée en mémoire d’un sous-système d’affichage, qui est illustrée dans l’illustration suivante.

Le sous-système d’affichage (qui est souvent une carte vidéo, mais qui peut être implémenté sur une carte mère) contient un GPU, un convertisseur numérique en analogique (DAC) et une mémoire. La chaîne d’échange est allouée dans cette mémoire pour rendre la présentation très rapide. Le sous-système d’affichage présente les données de la mémoire tampon frontale à la sortie.

Une chaîne d’échange est configurée pour afficher en mode plein écran ou en mode fenêtré, ceci élimine la nécessité de connaître le type de sortie, qu'elle soit en mode fenêtré ou en mode plein écran. Une chaîne d’échange en mode plein écran peut optimiser les performances en basculant la résolution d’affichage.

Créer une chaîne d’échange

Les mémoires tampons d’une chaîne d’échange sont créées à une taille particulière et dans un format particulier. L’application spécifie ces valeurs (ou vous pouvez hériter de la taille de la fenêtre cible) au démarrage, puis peut éventuellement les modifier en fonction du changement de la taille de la fenêtre en réponse aux entrées utilisateur ou aux événements du programme.

Après avoir créé la chaîne d’échange, vous souhaiterez généralement afficher des images dans celle-ci. Voici un fragment de code qui configure un contexte Direct3D à restituer dans une chaîne d’échange. Ce code extrait une mémoire tampon de la chaîne d’échange, crée une vue de rendu cible à partir de cette mémoire tampon, puis la définit sur l’appareil :

ID3D11Resource * pBB;
ThrowFailure( pSwapChain->GetBuffer(0, __uuidof(pBB),    
  reinterpret_cast<void**>(&pBB)), "Couldn't get back buffer");
ID3D11RenderTargetView * pView;
ThrowFailure( pD3D11Device->CreateRenderTargetView(pBB, NULL, &pView), 
  "Couldn't create view" );
pD3D11DeviceContext->OMSetRenderTargets(1, &pView, 0);
        

Après que votre application a rendu une image dans un tampon de chaîne d'échange, appelez IDXGISwapChain1::Present1. L’application peut ensuite afficher l’image suivante.

Soins et alimentation de la chaîne d’échange

Après avoir rendu votre image, appelez IDXGISwapChain1::Present1 et allez rendre l'image suivante. C’est l’étendue de votre responsabilité.

Si vous avez précédemment appelé IDXGIFactory ::MakeWindowAssociation, l’utilisateur peut appuyer sur la combinaison de touches Alt-Enter et DXGI fera passer votre application en mode fenêtre et plein écran. IDXGIFactory ::MakeWindowAssociation est recommandé, car un mécanisme de contrôle standard pour l’utilisateur est fortement souhaité.

Bien que vous n’ayez pas besoin d’écrire plus de code que ce qui a été décrit, quelques étapes simples peuvent rendre votre application plus réactive. La considération la plus importante est le redimensionnement des mémoires tampons de la chaîne d’échange en réponse au redimensionnement de la fenêtre de sortie. Naturellement, la meilleure route de l’application consiste à répondre à WM_SIZE et à appeler IDXGISwapChain ::ResizeBuffers, en passant la taille contenue dans les paramètres du message. Ce comportement rend évidemment votre application réagir efficacement à l’utilisateur lorsqu'il ou elle fait glisser les bordures de la fenêtre, mais c’est aussi exactement ce qui permet une transition fluide en plein écran. Votre fenêtre recevra un message WM_SIZE chaque fois qu'une telle transition se produit, et l'appel de IDXGISwapChain::ResizeBuffers est l'opportunité pour la chaîne d'échange de réallouer le stockage des tampons afin d'assurer une présentation optimale. C’est pourquoi l’application est tenue de libérer toutes les références qu’elle possède sur les mémoires tampons existantes avant d’appeler IDXGISwapChain ::ResizeBuffers.

Ne pas appeler IDXGISwapChain::ResizeBuffers en réponse au passage en mode plein écran (principalement en réponse à WM_SIZE) peut empêcher l'optimisation du basculement, où DXGI peut simplement échanger le tampon affiché, plutôt que de copier la totalité des données de l'écran.

IDXGISwapChain1::Present1 vous informe si votre fenêtre de sortie est entièrement obstruée via DXGI_STATUS_OCCLUDED. Lorsque cela se produit, nous vous recommandons d’utiliser votre application en mode de secours (en appelant IDXGISwapChain1 ::P resent1 avec DXGI_PRESENT_TEST), car les ressources utilisées pour restituer l’image sont perdues. L’utilisation de DXGI_PRESENT_TEST empêchera toute présentation des données tout en effectuant la vérification d’occlusion. Une fois que IDXGISwapChain1::Present1 retourne S_OK, vous devez quitter le mode veille ; n’utilisez pas le code de retour pour basculer en mode veille, car cela peut empêcher le swap chain de renoncer au mode plein écran.

Le runtime Direct3D 11.1, disponible à partir de Windows 8, fournit une chaîne d’échange de modèle inversé (autrement dit, une chaîne d’échange dont la valeur DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL est définie dans le membre SwapEffect de DXGI_SWAP_CHAIN_DESC ou de DXGI_SWAP_CHAIN_DESC1). Lorsque vous présentez des images à une sortie avec une chaîne d’échange de modèle inversé, DXGI annule la liaison de la mémoire tampon de retour à partir de tous les emplacements d’état du pipeline, comme une cible de rendu de fusion de sortie, qui écrivent dans la mémoire tampon 0. Par conséquent, nous vous recommandons d’appeler ID3D11DeviceContext ::OMSetRenderTargets immédiatement avant de vous rendre dans la mémoire tampon back. Par exemple, n’appelez pas OMSetRenderTargets, puis effectuez des opérations de calcul du nuanceur qui ne finissent pas par un rendu vers la ressource. Pour en savoir plus sur les chaînes de permutation du modèle flip et leurs avantages, consultez DXGI Flip Model.

Gestion du redimensionnement des fenêtres

Vous pouvez utiliser la méthode IDXGISwapChain ::ResizeBuffers pour gérer le redimensionnement de fenêtre. Avant d’appeler ResizeBuffers, vous devez libérer toutes les références en attente aux mémoires tampons de la chaîne d’échange. L’objet qui contient généralement une référence à la mémoire tampon d’une chaîne d’échange est une vue de rendu cible.

L’exemple de code suivant montre comment appeler ResizeBuffers à partir du gestionnaire WindowProc pour WM_SIZE messages :

    case WM_SIZE:
        if (g_pSwapChain)
        {
            g_pd3dDeviceContext->OMSetRenderTargets(0, 0, 0);

            // Release all outstanding references to the swap chain's buffers.
            g_pRenderTargetView->Release();

            HRESULT hr;
            // Preserve the existing buffer count and format.
            // Automatically choose the width and height to match the client rect for HWNDs.
            hr = g_pSwapChain->ResizeBuffers(0, 0, 0, DXGI_FORMAT_UNKNOWN, 0);
                                            
            // Perform error handling here!

            // Get buffer and create a render-target-view.
            ID3D11Texture2D* pBuffer;
            hr = g_pSwapChain->GetBuffer(0, __uuidof( ID3D11Texture2D),
                                         (void**) &pBuffer );
            // Perform error handling here!

            hr = g_pd3dDevice->CreateRenderTargetView(pBuffer, NULL,
                                                     &g_pRenderTargetView);
            // Perform error handling here!
            pBuffer->Release();

            g_pd3dDeviceContext->OMSetRenderTargets(1, &g_pRenderTargetView, NULL );

            // Set up the viewport.
            D3D11_VIEWPORT vp;
            vp.Width = width;
            vp.Height = height;
            vp.MinDepth = 0.0f;
            vp.MaxDepth = 1.0f;
            vp.TopLeftX = 0;
            vp.TopLeftY = 0;
            g_pd3dDeviceContext->RSSetViewports( 1, &vp );
        }
        return 1;

Choix de la sortie DXGI et de la taille

Par défaut, DXGI choisit la sortie qui contient la plupart de la zone cliente de la fenêtre. Il s'agit de la seule option disponible pour DXGI lorsqu'il passe en plein écran en réponse à la commande alt-enter. Si l’application choisit d’accéder en mode plein écran lui-même, elle peut appeler IDXGISwapChain ::SetFullscreenState et passer un IDXGIOutput1 explicite (ou NULL, si l’application est heureuse de laisser DXGI décider).

Pour redimensionner la sortie en plein écran ou en fenêtre, nous vous recommandons d’appeler IDXGISwapChain ::ResizeTarget, car cette méthode redimensionne également la fenêtre cible. Étant donné que la fenêtre cible est redimensionnée, le système d’exploitation envoie WM_SIZE, et votre code appelle naturellement IDXGISwapChain ::ResizeBuffers en réponse. Il s’agit donc d’un gaspillage d’efforts pour redimensionner vos mémoires tampons, puis redimensionner la cible.

Débogage en mode plein écran

Une chaîne d’échange DXGI abandonne le mode plein écran uniquement si nécessaire. Cela signifie que vous pouvez déboguer une application en plein écran à l’aide de plusieurs moniteurs, tant que la fenêtre de débogage ne chevauche pas la fenêtre cible de la chaîne d’échange. Alternativement, vous pouvez empêcher le changement de mode en ne définissant pas l’indicateur DXGI_SWAP_CHAIN_FLAG_ALLOW_MODE_SWITCH.

Si le changement de mode est autorisé, une chaîne d’échange abandonne le mode plein écran chaque fois que sa fenêtre de sortie est masquée par une autre fenêtre. La vérification d’occlusion est effectuée pendant IDXGISwapChain1 ::P resent1, ou par un thread distinct dont l’objectif est de voir si l’application ne répond plus (et n’appelle plus IDXGISwapChain1 ::P resent1). Pour désactiver la capacité du thread distinct à provoquer un commutateur, définissez la clé de Registre suivante sur n’importe quelle valeur différente de zéro.

HKCU\Software\Microsoft\DXGI\DisableFullscreenWatchdog

Destruction d’une chaîne d’échange

Vous ne pouvez pas libérer une swap chain en mode plein écran, car cela peut créer une contention de thread (ce qui entraînera le déclenchement d'une exception non continuable DXGI). Avant de libérer une chaîne d’échange, passez d’abord en mode fenêtré (à l’aide de IDXGISwapChain ::SetFullscreenState( FALSE, NULL )) puis appelez IUnknown ::Release.

Utilisation d’un moniteur pivoté

Une application n’a pas besoin de se soucier de l’orientation du moniteur, DXGI fait pivoter le tampon de la chaîne d'échange lors de la présentation, si nécessaire. Bien sûr, cette rotation supplémentaire peut avoir un impact sur les performances. Pour des performances optimales, prenez soin de la rotation dans votre application en procédant comme suit :

• Utilisez le DXGI_SWAP_CHAIN_FLAG_NONPREROTATED. Cela informe DXGI que l’application produira une image pivotée (par exemple, en modifiant sa matrice de projection). Une chose à noter, cet indicateur n’est valide qu’en mode plein écran.
• Allouez chaque mémoire tampon de chaîne d’échange dans sa taille pivotée. Utilisez IDXGIOutput ::GetDesc pour obtenir ces valeurs, si nécessaire.

En effectuant la rotation dans votre application, DXGI effectue simplement une copie au lieu d’une copie et d’une rotation.

Le runtime Direct3D 11.1, disponible à partir de Windows 8, fournit une chaîne d’échange de modèle inversé (autrement dit, une chaîne d’échange dont la valeur DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL est définie dans le membre SwapEffect de DXGI_SWAP_CHAIN_DESC1). Pour tirer parti des optimisations de présentation disponibles avec une chaîne de permutation de modèle inversé, nous vous recommandons d'orienter le contenu des applications pour qu'il s'aligne avec le dispositif de sortie spécifique sur lequel il réside lorsque ce contenu occupe pleinement la sortie. Pour plus d’informations sur les chaînes d’échange de modèle flip et leurs avantages, consultez DXGI Flip Model.

Changement de modes

La chaîne d’échange DXGI peut modifier le mode d’affichage d’une sortie lors de la transition plein écran. Pour activer la modification automatique du mode d’affichage, vous devez spécifier DXGI_SWAP_CHAIN_FLAG_ALLOW_MODE_SWITCH dans la description de la chaîne d’échange. Si le mode d’affichage change automatiquement, DXGI choisit le mode le plus modeste (la taille et la résolution ne changent pas, mais la profondeur de couleur peut). Le redimensionnement des mémoires tampons de chaîne d’échange n’entraîne pas de changement de mode. La chaîne d’échange promet implicitement que si vous choisissez une mémoire tampon de retour qui correspond exactement à un mode d’affichage pris en charge par la sortie cible, il bascule vers ce mode d’affichage lors de l’entrée en mode plein écran sur cette sortie. Par conséquent, vous choisissez un mode d’affichage en choisissant la taille et le format de votre mémoire tampon arrière.

Conseil pour la performance en plein écran

Lorsque vous appelez IDXGISwapChain1::Present1 sur une application en plein écran, la chaîne d’échange effectue un flip (au lieu d'effectuer des blits) du contenu du tampon arrière vers le tampon avant. Cela nécessite que la chaîne d’échange a été créée à l’aide d’un mode d’affichage énuméré (spécifié dans DXGI_SWAP_CHAIN_DESC1). Si vous ne parvenez pas à énumérer les modes d’affichage ou si vous spécifiez incorrectement le mode d’affichage dans la description, la chaîne d’échange peut effectuer un transfert de bloc de bits (bitblt) à la place. Le bitblt provoque une copie d’étirement supplémentaire ainsi qu’une utilisation accrue de la mémoire vidéo, et est difficile à détecter. Pour éviter ce problème, énumérez les modes d’affichage et initialisez correctement la description de la chaîne d’échange avant de créer la chaîne d’échange. Cela garantit des performances maximales lors du basculement en mode plein écran et évite la surcharge de mémoire supplémentaire.

Considérations sur les multithreads

Lorsque vous utilisez DXGI dans une application avec plusieurs threads, veillez à éviter de créer un interblocage, où deux threads différents attendent de se terminer. Il existe deux situations où cela peut se produire.

• Le thread de rendu n’est pas le thread de gestion des messages.
• Le thread exécutant une API DXGI n’est pas le même thread que celui qui a créé la fenêtre.

Veillez à ce que le fil de la pompe de messages n'attende jamais sur le fil de rendu lorsque vous utilisez des chaînes d'échange en plein écran. Par exemple, l’appel d’IDXGISwapChain1::Present1 (à partir du thread de rendu) peut entraîner l’attente du thread de rendu sur le thread de gestion de messages. Lorsqu’une modification de mode se produit, ce scénario est possible si Present1 appelle ::SetWindowPos() ou ::SetWindowStyle() et l’une de ces méthodes appelle ::SendMessage(). Dans ce scénario, si le thread de pompe de messages a une section critique qui la protège ou si le thread de rendu est bloqué, les deux threads sont bloqués.

Pour plus d’informations sur l’utilisation de DXGI avec plusieurs threads, consultez Multithreading et DXGI.

Réponses DXGI de DLLMain

Étant donné qu’une fonction DllMain ne peut pas garantir l’ordre dans lequel elle charge et décharge des DLL, nous vous recommandons de ne pas appeler la fonction DllMain de votre application, ni les fonctions ou méthodes Direct3D ou DXGI, y compris les fonctions ou méthodes qui créent ou libèrent des objets. Si la fonction DllMain de votre application appelle un composant particulier, ce composant peut appeler une autre DLL qui n’est pas présente sur le système d’exploitation, ce qui provoque le blocage du système d’exploitation. Direct3D et DXGI peuvent charger un ensemble de DLL, généralement un ensemble de pilotes, qui diffère de l’ordinateur à l’ordinateur. Par conséquent, même si votre application ne se bloque pas sur vos ordinateurs de développement et de test lorsque sa fonction DllMain appelle des fonctions ou méthodes Direct3D ou DXGI, elle peut se bloquer lorsqu’elle s’exécute sur un autre ordinateur.

Pour vous empêcher de créer une application susceptible de provoquer le blocage du système d’exploitation, DXGI fournit les réponses suivantes dans les situations spécifiées :

• Si la fonction DllMain de votre application publie sa dernière référence à une fabrique DXGI, DXGI déclenche une exception.
• Si la fonction DllMain de votre application crée une fabrique DXGI, DXGI retourne un code d’erreur.

Modifications de DXGI 1.1

Nous avons ajouté les fonctionnalités suivantes dans DXGI 1.1.

• Prise en charge des Surfaces partagées synchronisées

  Les surfaces partagées synchronisées pour Direct3D 10.1 et Direct3D 11 permettent un partage efficace de surface de lecture et d’écriture entre plusieurs appareils Direct3D (le partage entre les appareils Direct3D 10 et Direct3D 11 est possible). Consultez IDXGIKeyedMutex ::AcquireSync et IDXGIKeyedMutex ::ReleaseSync.

• Prise en charge haute couleur

  Prend en charge le format DXGI_FORMAT_R10G10B10_XR_BIAS_A2_UNORM.

• IDXGIDevice1 ::SetMaximumFrameLatency et IDXGIDevice1 ::GetMaximumFrameLatency

• IDXGIFactory1 ::EnumAdapters1 énumère les adaptateurs locaux sans moniteurs ou sorties attachés, ainsi que les adaptateurs avec des sorties attachées. Le premier adaptateur renvoyé sera l'adaptateur local sur lequel l'élément principal du bureau est affiché.

• Prise en charge du format BGRA

  DXGI_FORMAT_B8G8R8A8_UNORM et DXGI_FORMAT_B8G8R8A8_UNORM_SRGB, consultez IDXGISurface1::GetDC et IDXGISurface1::ReleaseDC.

Modifications de DXGI 1.2

Nous avons ajouté les fonctionnalités suivantes dans DXGI 1.2.

• Chaîne d’échange stéréo
• Chaîne d’échange de modèle inversé
• Présentation optimisée (défilement, rectangles sales et rotation)
• Amélioration des ressources partagées et de la synchronisation
• Duplication d'écran de bureau
• Utilisation optimisée de la mémoire vidéo
• Prise en charge des formats de 16 bits par pixel (DXGI_FORMAT_B5G6R5_UNORM, DXGI_FORMAT_B5G5R5A1_UNORM, DXGI_FORMAT_B4G4R4A4_UNORM)
• Débogage d’API

Pour plus d’informations sur DXGI 1.2, consultez Améliorations apportées à DXGI 1.2.

Compatibilité des applications

DXGI peut appliquer des modifications de comportement d’application pour améliorer la compatibilité des applications.

• Les paramètres de compatibilité peuvent être stockés dans le registre utilisateur sous HKCU\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\AppCompatFlags\Layers.
• Les paramètres de compatibilité peuvent ou non être appliqués en fonction de la configuration du système ou d’autres facteurs.
• Un exemple de valeur de paramètre de compatibilité d’application est DXAllowModeChangeOnLaunch720.

Rubriques connexes

Guide de programmation pour DXGI