Interopérabilité de WPF : vue d'ensemble des zones de fenêtre et de l'espace de rendu

Mise à jour : novembre 2007

L'« espace de rendu » ('airspace' en anglais) est une façon conceptuelle de penser sur la manière dont les deux moitiés d'une application d'interopérabilité partagent les zones de rendu dans une fenêtre de niveau supérieur commune. Cette rubrique explique comment le concept d'« espace de rendu » peut influencer la conception de présentation, ainsi que les considérations d'entrée pour votre application d'interopérabilité de WPF.

Espace de rendu

Dans une fenêtre de niveau supérieur, vous pouvez conceptualiser le fait que chaque HWND qui comprend l'une des technologies d'une application d'interopérabilité dispose de son propre « espace de rendu ». Chaque pixel de la fenêtre appartient exactement à un HWND, qui constitue l'espace de rendu de ce HWND. (En principe, il existe plusieurs espaces de rendu WPF s'il existe plusieurs HWND WPF, mais afin d'expliquer le concept, les exemples fournis dans cette rubrique supposent qu'il n'en existe qu'un seul.) Le concept d'espace de rendu implique que toutes les couches ou autres fenêtres qui tentent de restituer au-dessus de ce pixel pendant la durée de vie d'application doivent faire partie de la même technologie de niveau de rendu. En tentant de restituer des pixels WPF sur Win32, vous obtenez des résultats indésirables. Cette opération est rejetée autant que possible dans les API d'interopérabilité.

Exemples d'espace de rendu

Le premier exemple illustre une application qui combine Win32, DirectX et WPF. Chaque technologie utilise son propre jeu séparé non superposé de pixels et l'espace de rendu ne pose aucun problème.

Supposez que vous démarrez à partir de cette application et créez une animation qui est contrôlée par la position du pointeur de la souris et qui peut donc tenter de rendre sur chacune de ces trois régions. L'espace de rendu s'en trouverait finalement violé. Quelle que soit la technologie responsable de l'animation elle-même, cette technologie viole l'espace de rendu des deux autres. Ce problème est illustré dans l'image suivante où le cercle vert essaie de se déplacer dans la fenêtre :

Autre violation d'espace de rendu : vous essayez d'utiliser la transparence/fusion alpha entre des technologies différentes. Dans l'image ci-dessous, la zone WPF viole les espaces de rendu Win32 et DirectX. Comme les pixels de cette zone WPF sont semi-transparents, ils devraient être possédés conjointement par DirectX et WPF, ce qui n'est pas possible. Il s'agit donc d'une autre violation de l'espace de rendu, qui ne peut pas être générée :

Les trois exemples précédents ont utilisé des régions rectangulaires, mais l'espace de rendu n'est pas nécessairement rectangulaire. Il peut s'agir d'un rectangle avec un trou (par exemple, l'espace de rendu Win32 ici est tout sauf les espaces de rendu WPF et DirectX) :

Les espaces de rendu peuvent également prendre une forme totalement non rectangulaire ou toute forme pouvant être décrite par un HRGN Win32 (région) :

Transparence et fenêtres de niveau supérieur

Le processus de gestionnaire de fenêtre (dans Windows Vista et Microsoft Windows XP) traite uniquement vraiment les HWND Win32. Par conséquent, chaque WPFWindow est un HWND. Le HWND Window doit se conformer aux règles générales de tout HWND. Dans ce HWND, le code WPF peut faire tout ce que les API WPF prennent en charge. En revanche, pour les interactions avec d'autres HWND sur le Bureau, WPF doit se conformer aux règles de traitement et de rendu de Win32. WPF prend en charge les fenêtres non rectangulaires à l'aide des API Win32 (des HRGN pour des fenêtres non rectangulaires et des fenêtres superposées pour un alpha par pixel).

La valeur alpha constante et les clés de couleur ne sont pas prises en charge. Les fonctions de fenêtre superposée Win32 varient selon la plateforme.

Les fenêtres superposées peuvent rendre toute la fenêtre translucide (semi-transparente) en spécifiant une valeur alpha à appliquer à chaque pixel de la fenêtre. (En fait, Win32 prend en charge l'alpha par pixel, mais il est très difficile à utiliser dans les programmes pratiques car, dans ce mode, vous devez dessiner vous-même tous les enfants HWND, y compris les boîtes de dialogue et les menus déroulants).

WPF prend en charge les HRGN. Il n'existe toutefois pas d'API managées pour ces fonctionnalités. Vous pouvez utiliser l'appel de code non managé et HwndSource pour appeler les API Win32 appropriées. Pour plus d'informations, consultez Appel à des fonctions natives à partir de code managé.

Les fenêtres superposées WPF ont des fonctions différentes sur différents systèmes d'exploitation (parce que WPF utilise DirectX pour le rendu et que les fenêtres superposées ont été conçues à l'origine pour le rendu GDI, pas pour le rendu DirectX) :

• WPF prend en charge les fenêtres superposées accélérées par le matériel sur Windows Vista. Comme les fenêtres superposées accélérées par le matériel sur Microsoft Windows XP requièrent la prise en charge de Microsoft DirectX, les fonctions dépendront de la version de Microsoft DirectX sur cet ordinateur.

• WPF ne prend pas en charge les clés de couleur de transparence car il ne peut pas garantir de rendre la couleur exacte demandée, surtout lorsque le rendu est accéléré par le matériel.

• En cas d'exécution sur Microsoft Windows XP, les fenêtres superposées sur des surfaces DirectX scintillent lors du rendu de l'application DirectX. (La séquence de rendu réelle est la suivante : interface graphique GDI (Graphics Device Interface) Microsoft Windows masque la fenêtre superposée, puis DirectX dessine, puis interface graphique GDI (Graphics Device Interface) Microsoft Windows remet la fenêtre superposée.) Les fenêtres superposées non-WPF connaissent également cette limitation.

Voir aussi

Tâches

Didacticiel : créer une application Win32 hébergeant du contenu WPF

Didacticiel : créer une application WPF hébergeant du contenu Win32

Concepts

Vue d'ensemble de l'interopérabilité WPF et Win32