Vue d'ensemble des régions de technologie

Si plusieurs technologies de présentation sont utilisées dans une application, telles que WPF, Win32 ou DirectX, elles doivent partager les zones de rendu dans une fenêtre de niveau supérieur commune. Cette rubrique décrit les problèmes qui peuvent influencer la présentation et la saisie pour votre application d'interopérabilité WPF.

Régions

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 sa propre région (ou « espace de rendu »). Chaque pixel de la fenêtre appartient exactement à un HWND, qui constitue la région de ce HWND. (À proprement parler, il existe plusieurs régions WPF s'il existe plusieurs HWND WPF, mais pour les besoins de cette discussion, vous pouvez supposer qu'il n'en existe qu'une seule). Le concept de région 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 APIs d'interopérabilité.

Exemples de région

L'illustration suivante montre une application qui mélange Win32, DirectX et WPF. Chaque technologie utilise son propre jeu séparé non superposé de pixels et la région ne pose aucun problème.

Supposez que cette application utilise la position du pointeur de la souris pour créer une animation qui tente de s'afficher dans l'une de ces trois régions. Quelle que soit la technologie responsable de l'animation elle-même, cette technologie viole la région des deux autres. L'illustration suivante montre une tentative de rendu d'un cercle WPF dans une région Win32.

Autre violation : vous essayez d'utiliser la transparence/fusion alpha entre des technologies différentes. Dans l'illustration suivante, la zone WPF viole les régions 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 existe donc une autre violation et la génération est impossible.

Les trois exemples précédents ont utilisé des régions rectangulaires, mais les différentes formes sont possibles. Par exemple, une région peut présenter un trou. L'illustration suivante montre une région Win32 avec un trou rectangulaire de la taille des régions WPF et DirectX combinées.

Les régions 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 gestionnaire de fenêtrage Windows ne traite vraiment que les HWDN Win32. Par conséquent, chaque Window WPF 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 APIs 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 Win32 APIs (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'APIs managées pour ces fonctionnalités. Vous pouvez utiliser l'appel de code non managé et HwndSource pour appeler les APIs Win32 appropriées. Pour plus d'informations, consultez Appel à des fonctions natives à partir de code managé.

Les fenêtres WPF superposées ont des fonctions différentes sur des systèmes d'exploitation différents. Cela est dû au fait que WPF utilise DirectX pour s'afficher, et que les fenêtres superposées ont été principalement conçues pour le rendu de GDI, pas de DirectX.

• WPF prend en charge les fenêtres superposées accélérées par le matériel sur Windows Vista et versions ultérieures. 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.

• Si votre application est exécutée 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 : Microsoft Windows Graphics Device Interface (GDI) masque la fenêtre superposée, puis DirectX dessine, puis Microsoft Windows Graphics Device Interface (GDI) remet la fenêtre superposée.) Les fenêtres superposées non-WPF connaissent également cette limitation.

Voir aussi

Tâches

Procédure pas à pas : hébergement d'un WPF Clock dans Win32

Hébergement de contenu Win32 dans WPF

Concepts

Interopérabilité WPF et Win32