Partage via

Hébergement fenêtré par rapport à l’hébergement visuel de WebView2

  • Article

Il existe trois options pour héberger le contrôle Microsoft Edge WebView2 dans votre application :

  • Mode d’hébergement fenêtré.
  • Mode d’hébergement Fenêtre vers visuel.
  • Mode d’hébergement visuel.

Vous n’avez pas besoin de lire cet article si vous utilisez l’hébergement fenêtré dans la plupart des scénarios. L’hébergement fenêtré est un bon point de départ pour la plupart des applications. Lisez cet article :

  • Si vous utilisez l’hébergement fenêtré dans des scénarios inhabituels et que vous rencontrez des problèmes persistants de résolution et de mise à l’échelle. Dans ce cas, envisagez l’hébergement de fenêtre à visuel.
  • Si vous souhaitez fournir une expérience utilisateur (UX) plus personnalisée. Dans ce cas, envisagez l’hébergement visuel.

Les différentes approches pour l’hébergement du contrôle WebView2 dans votre application sont similaires en termes de fonctionnalités, mais elles répondent à différents besoins en fonction des exigences de l’application, comme suit :

Approche Description Optimisé pour
Hébergement fenêtré Le contrôle WebView2 prend l’entrée du système d’exploitation. Le système d’exploitation envoie l’entrée au WebView2. Affichage rapide et facile du contenu web, sans avoir à inclure de fonctionnalités pour les entrées, les sorties et l’accessibilité.
Hébergement de fenêtre à visuel Combinaison d’hébergement fenêtré et visuel. Similaire à l’hébergement fenêtré, à ceci près que le contenu WebView2 est généré vers un visuel hébergé dans une fenêtre plutôt que d’avoir une sortie de contenu vers la fenêtre directement. Une expérience de développement presque identique à l’hébergement fenêtré, mais avec une gestion améliorée de la résolution/de la mise à l’échelle et la mise en garde que l’expérience d’écriture manuscrite Windows Shell n’est pas prise en charge.
Hébergement de visuels Votre application hôte prend une entrée spatiale (telle que l’entrée de la souris ou tactile) de l’utilisateur. Votre application envoie cette entrée au contrôle WebView2. Contrôle plus granulaire de la composition du contrôle. L’application doit effectuer une gestion spécifique des API de gestion et de rendu des fenêtres.

Ces approches ont des exigences, des contraintes et des avantages différents.

  • L’hébergement fenêtré est plus simple à implémenter que l’hébergement visuel.
  • L’hébergement visuel nécessite tous les appels d’API requis par l’hébergement fenêtré et a des exigences supplémentaires pour qu’il s’affiche correctement.

Les listes d’API prises en charge sont liées dans les sections ci-dessous :

Hébergement fenêtré : pour afficher du contenu rapidement et facilement

L’hébergement fenêtré signifie que dans votre application, le contenu WebView2 est hébergé directement dans une fenêtre ; c’est-à-dire un HWND. WebView2 HWND hérite de nombreuses propriétés par défaut du système d’exploitation. Le contrôle WebView2 prend l’entrée du système d’exploitation, et le système d’exploitation envoie l’entrée au contrôle WebView2. Vous pouvez avoir plusieurs HWND dans votre application qui seront utilisés comme composant WebView2 pour accéder au contenu web.

L’avantage est que certaines commandes d’entrée/sortie sont gérées pour vous par le système d’exploitation ou par l’infrastructure. Toutefois, vous devrez toujours gérer certains aspects de la gestion des fenêtres.

Pour obtenir des informations générales sur la gestion et HWND les fonctionnalités des fenêtres, consultez À propos de Windows.

Avantages

  • L’hébergement fenêtré permet une solution qui affiche rapidement du contenu web sans avoir à implémenter de fonctionnalités pour les entrées, les sorties et l’accessibilité.

  • Les fenêtres détenues et enfants (telles que les menus et les menus contextuels) sont automatiquement mises à l’échelle pour correspondre à la mise à l’échelle parente HWND de l’application.

  • L’hébergement fenêtré gère la façon dont le contrôle WebView2 gère le focus et la tabulation de lui-même lorsque l’appui sur Tab atteint l’élément final.

  • Vous n’avez pas besoin de gérer les différents contrôles de rendu basés sur la composition (tels que les contrôles Entrées, Sorties et Accessibilité) si vous ne le souhaitez pas.

Inconvénients

Le mode d’hébergement fenêtré peut rencontrer des problèmes ppp dans certains scénarios, par exemple lors du partage d’un dossier de données utilisateur (et du partage d’un processus de navigateur) entre différentes applications avec une connaissance ppp différente.

API pour l’hébergement fenêtré

Pour obtenir la liste des API qui peuvent être utilisées lors de la configuration de WebView2 pour l’hébergement fenêtré (ou pour l’hébergement de fenêtre à visuel), consultez Rendu de WebView2 dans les applications non-framework dans Vue d’ensemble des fonctionnalités et API WebView2.

Hébergement de fenêtre à visuel : pour une expérience similaire à l’hébergement fenêtré, avec des avantages supplémentaires et des compromis

L’hébergement de fenêtre à visuel signifie que le contenu WebView2 est généré vers un élément visuel hébergé dans un HWND, plutôt que de placer du contenu directement dans une fenêtre ou dans un visuel. En hébergeant du contenu dans un HWND, l’hébergement de fenêtre à visuel est facile à utiliser, de la même manière que l’hébergement fenêtré. Toutefois, en affichant du contenu à l’aide d’un élément visuel, l’hébergement de fenêtre à visuel évite certains problèmes DPI et d’entrée qui peuvent se produire lors de l’utilisation de l’hébergement fenêtré.

L’hébergement de fenêtre à visuel ne nécessite pas l’utilisation des API d’hébergement de visuel WebView2.

Pour activer l’hébergement De fenêtre à visuel, la variable COREWEBVIEW2_FORCED_HOSTING_MODE d’environnement doit être définie sur la valeur COREWEBVIEW2_HOSTING_MODE_WINDOW_TO_VISUAL avant d’initialiser votre WebView2.

Dans hébergement de fenêtre à visuel et hébergement visuel, un visuel est une unité graphique de base qui peut être utilisée pour composer des expériences graphiques sur Windows. Les API graphiques Windows qui exposent cette fonctionnalité et qui sont pertinentes pour WebView2 sont DirectComposition et Windows.UI.Composition. Le « Visuel » dans « Hébergement visuel » peut être l’un des IDCompositionVisualéléments visuels , IDCompositionTargetou Windows.UI.Composition.Visual, qui sont des visuels exposés via les DirectComposition API et Windows.UI.Composition . (L’hébergement de fenêtre à visuel utilise IDCompositionVisual spécifiquement.) Voir:

  • Concepts de base dans la documentation Développement d’applications > Windows DirectComposition.
  • Visuel de composition dans la documentation UWP développement > d’applications Windows.

Avantages

  • Différentes applications qui partagent un dossier de données utilisateur WebView2 peuvent avoir une connaissance DPI différente.

  • Différentes applications qui partagent un dossier de données utilisateur WebView2 peuvent avoir différents niveaux d’intégrité.

  • Les différentes applications qui partagent un dossier de données utilisateur WebView2 ne se bloquent pas mutuellement en raison de files d’attente d’entrée de fenêtre attachées.

  • Lors de l’hébergement d’un WebView2 dans un complément VSTO, la modification de l’échelle du moniteur n’entraîne pas potentiellement le blocage de l’application. Consultez Compléments VSTO dans vue d’ensemble du développement de solutions Office (VSTO).

Inconvénients

L’activation du mode d’hébergement De fenêtre à visuel supprime la prise en charge de l’écriture manuscrite Windows Shell dans WebView2.

Voir aussi :

API pour l’hébergement de fenêtre à visuel

Pour obtenir la liste des API qui peuvent être utilisées lors de la configuration de la fenêtre WebView2 sur l’hébergement visuel (ou pour l’hébergement fenêtré), consultez Rendu de WebView2 dans les applications non-framework dans Vue d’ensemble des fonctionnalités et API WebView2.

Hébergement visuel : pour un contrôle plus précis de la disposition

Lorsque vous utilisez l’hébergement visuel, votre application hôte reçoit une entrée spatiale (par exemple, une entrée de souris ou tactile) de l’utilisateur et transfère cette entrée au contrôle WebView2. L’hébergement visuel nécessite que l’application effectue la même gestion des fenêtres que l’hébergement fenêtré, mais a des exigences supplémentaires en matière de gestion des fenêtres concernant :

  • Mise à l’échelle du contenu.
  • Routage des entrées spatiales (telles que la souris, l’interaction tactile ou le stylet).

Configuration requise pour la mise à l’échelle du contenu

Selon le rendu basé sur la composition, un contrôle WebView2 fait partie d’une arborescence d’éléments visuels. Par conséquent, par défaut, il est rendu à une échelle basée sur les échelles de tous ses visuels ancêtres. Par exemple, si le visuel ancêtre d’un WebView2 est mis à l’échelle (zoomé) 2x, le contenu du WebView2 est également rendu à l’échelle 2x. Si le visuel parent du WebView2 est mis à l’échelle 2x et que le parent de ce visuel est également mis à l’échelle 2x, le WebView2 est mis à l’échelle 4 fois. Toutefois, étant donné que WebView2 ne met pas à l’échelle son propre contenu, il est flou.

Pour résoudre ce problème, l’application peut annuler la mise à l’échelle visuelle par défaut de WebView2 et utiliser à la place les API de mise à l’échelle de rastérisation pour appliquer la mise à l’échelle visuelle prévue. Le contenu du WebView2 est alors affiché à l’échelle appropriée. Consultez Échelle de rastérisation dans Vue d’ensemble des fonctionnalités et API WebView2.

Configuration requise pour le routage des entrées spatiales (souris, interaction tactile ou stylet)

Si votre application WebView2 utilise l’hébergement visuel, aucune entrée spatiale (telle que la souris, l’interaction tactile ou le stylet) n’est envoyée au contrôle WebView2, sauf si l’application gère une telle entrée. L’entrée est envoyée au serveur de HWNDl’application et l’application est chargée de transférer cette entrée spatiale au WebView2, si la position de l’entrée est sur le WebView2.

L’application est également responsable de toute transformation nécessaire des positions d’entrée dans l’espace de coordonnées du WebView2.

Voir aussi :

Avantages et inconvénients

L’hébergement visuel permet (et nécessite) un contrôle plus précis de la disposition. Lorsque vous utilisez cette approche, l’application a besoin d’une gestion spécifique des API de gestion et de rendu des fenêtres.

Par exemple, si une action de l’utilisateur entraîne la mise à l’échelle de l’arborescence visuelle de WebView2, l’application doit ajuster l’échelle de WebView2 pour qu’elle s’affiche correctement par rapport à ses visuels parents.

API pour l’hébergement de visuels

Pour obtenir la liste des API qui peuvent être utilisées lors de la configuration de WebView2 dans un environnement d’hébergement visuel, consultez Rendu de WebView2 à l’aide de la composition dans Vue d’ensemble des fonctionnalités et API WebView2.

Compatibilité et contraintes

Les principales limitations de compatibilité incluent le système d’exploitation et le rendu dans les applications d’infrastructure et non-framework.

Systèmes d’exploitation

Tous les modes d’hébergement sont pris en charge partout où WebView2 est pris en charge ; c’est-à-dire Windows 10 et versions ultérieures, et certaines versions de Windows Server. Windows 7, 8 et 8.1 ne sont plus pris en charge ; Windows 7 et Windows 8 prennent uniquement en charge l’hébergement fenêtré, et non l’hébergement visuel.

Voir aussi :

Contraintes d’infrastructure

CreateCoreWebView2CompositionControllerne prend pas en charge les visuels WinAppSDK ; c’est-à-dire des objets visuels dans l’espace Microsoft.UI.Composition de noms, décrits dans Améliorer l’interface utilisateur avec la couche visuelle (SDK d'application Windows/WinUI 3).

Voir aussi

Externe: