次の方法で共有

WebView2 のウィンドウホスティングとビジュアル ホスティング

アプリで Microsoft Edge WebView2 コントロールをホストするには、次の 3 つのオプションがあります。

  • ウィンドウ ホスティング モード。
  • ウィンドウからビジュアルへのホスティング モード。
  • ビジュアル ホスティング モード。

ほとんどのシナリオで Windowed ホスティングを使用する場合は、この記事を読む必要はありません。 ウィンドウホスティングは、ほとんどのアプリにとって良い出発点です。 この記事をお読みください。

  • 一般的でないシナリオで Windowed ホスティングを使用していて、DPI とスケーリングで永続的な問題が発生している場合。 この場合は、Window to Visual ホスティングを検討してください。
  • よりカスタム ユーザー エクスペリエンス (UX) を提供する場合。 この場合は、Visual ホスティングを検討してください。

アプリで WebView2 コントロールをホストするためのさまざまな方法は機能に似ていますが、次のようにアプリの要件に応じて異なるニーズに合っています。

方法 説明 最適化対象
ウィンドウ ホスティング WebView2 コントロールは、オペレーティング システム (OS) から入力を受け取ります。 OS は、入力を WebView2 に送信します。 入力、出力、アクセシビリティの機能を含めなくても、Web コンテンツをすばやく簡単に表示できます。
ウィンドウからビジュアルへのホスティング Windowed ホスティングと Visual ホスティングの組み合わせ。 ウィンドウホスティングと同様に、WebView2 コンテンツは、ウィンドウに直接コンテンツ出力を持つ代わりにウィンドウでホストされている Visual に出力されます。 開発者エクスペリエンスは Windowed ホスティングとほぼ同じですが、DPI/スケーリング処理が向上し、Windows シェル手書き操作がサポートされていないことに注意してください。
ビジュアル ホスティング ホスト アプリは、ユーザーから空間入力 (マウスやタッチ入力など) を受け取ります。 アプリは、この入力を WebView2 コントロールに送信します。 コントロールの構成に対するより詳細な制御。 アプリでは、ウィンドウ管理とレンダリング API の特定の処理を行う必要があります。

これらのアプローチには、さまざまな要件、制約、および利点があります。

  • ウィンドウ ホスティングは、Visual ホスティングよりも簡単に実装できます。
  • ビジュアル ホスティングには、Windowed ホスティングに必要なすべての API 呼び出しが必要であり、適切にレンダリングするための追加の要件があります。

サポートされている API リストは、以下のセクションにリンクされています。

ウィンドウ ホスティング: コンテンツをすばやく簡単に表示する

ウィンドウ ホスティング とは、アプリ内で WebView2 コンテンツがウィンドウ内で直接ホストされることを意味します。つまり、HWND です。 WebView2 HWND は、オペレーティング システム (OS) から多くの既定のプロパティを継承します。 WebView2 コントロールは OS から入力を受け取り、OS は入力を WebView2 コントロールに送信します。 アプリに複数の HWND を含めることができます。この HWND はそれぞれ WebView2 コンポーネントとして使用され、Web コンテンツにアクセスできます。

この利点は、入力/出力コマンドの一部が OS またはフレームワークによって自動的に処理される点です。 ただし、ウィンドウ管理のいくつかの側面を処理する必要があります。

ウィンドウの管理と HWND 機能の一般的な情報については、「 Windows について」を参照してください。

メリット

  • ウィンドウ ホスティングを使用すると、入力、出力、アクセシビリティの機能を実装することなく、Web コンテンツをすばやく表示するソリューションが可能になります。

  • 所有ウィンドウと子ウィンドウ (メニューやコンテキスト メニューなど) は、アプリの親 HWND スケーリングに合わせて自動的にスケーリングされます。

  • ウィンドウ ホスティングは、Tab キーを押すと最終的な要素に到達したときに、WebView2 コントロールがフォーカスを置いたり、それ自体から タブ を移動したりする方法を処理します。

  • 必要がない場合は、さまざまな合成ベースのレンダリング コントロール (入力、出力、アクセシビリティ コントロールなど) を管理する必要はありません。

デメリット

ウィンドウ ホスティング モードでは、DPI 認識が異なるさまざまなアプリケーション間でユーザー データ フォルダーを共有する (ブラウザー プロセスを共有する) 場合など、一部のシナリオで DPI の問題が発生する可能性があります。

ウィンドウ ホスティング用の API

WebView2 for Windowed ホスティング (または Window to Visual ホスティング) を構成するときに使用できる API の一覧については、「WebView2 の機能と API の概要」の「フレームワーク以外のアプリでの WebView2 のレンダリング」を参照してください。

ウィンドウからビジュアルへのホスティング: Windowed ホスティングと同様のエクスペリエンスを実現し、利点とトレードオフを追加しました

ウィンドウからビジュアルへのホスト は、WebView2 コンテンツが、ウィンドウに直接または Visual に直接コンテンツを出力するのではなく、HWND でホストされている Visual に出力されることを意味します。 HWND でコンテンツをホストすることで、Window to Visual ホスティングは Windowed ホスティングと同じ方法で簡単に使用できます。 ただし、Visual を使用してコンテンツを表示することで、Window-to-Visual ホスティングでは、Windowed ホスティングを使用するときに発生する可能性のある DPI と入力の問題を回避できます。

ウィンドウからビジュアルへのホスティングでは、WebView2 Visual ホスティング API を使用する必要はありません。

Window to Visual ホスティングを有効にするには、環境変数 COREWEBVIEW2_FORCED_HOSTING_MODE 、WebView2 を初期化する前に COREWEBVIEW2_HOSTING_MODE_WINDOW_TO_VISUAL 値に設定する必要があります。

Window-to-Visual ホスティングと Visual ホスティングでは、 Visual は基本的なグラフィカル ユニットであり、Windows でグラフィカル エクスペリエンスを作成するために使用できます。 この機能を公開し、WebView2 に関連する Windows グラフィックス API はDirectCompositionWindows.UI.Composition。 "Visual ホスティング" の "Visual" には、 IDCompositionVisual、 IDCompositionTarget、 Windows.UI.Composition.Visualのいずれかを指定できます。これは、 DirectComposition API と Windows.UI.Composition API を介して公開されるビジュアルです。 (ウィンドウからビジュアルへのホスティングでは、 IDCompositionVisual を具体的に使用します)。見る：

メリット

  • WebView2 ユーザー データ フォルダーを共有するアプリによって、DPI 認識が異なる場合があります。

  • WebView2 ユーザー データ フォルダーを共有するアプリごとに、異なる整合性レベルを持つことができます。

  • WebView2 ユーザー データ フォルダーを共有する異なるアプリでは、ウィンドウ入力キューがアタッチされているために互いにハングする可能性はありません。

  • VSTO アドインで WebView2 をホストする場合、モニタースケールを変更してもアプリがハングする可能性はありません。 Office ソリューション開発の概要 (VSTO) の VSTO アドインに関するページを参照してください。

デメリット

Window to Visual ホスティング モードを有効にすると、WebView2 内での Windows シェル手書きのサポートが削除されます。

関連項目:

Window to Visual ホスティングの API

WebView2 Window to Visual ホスティング (またはウィンドウ ホスティング) を構成するときに使用できる API の一覧については、「WebView2 の機能と API の概要」の「フレームワーク以外のアプリでの WebView2 のレンダリング」を参照してください。

ビジュアル ホスティング: レイアウトをより詳細に制御する

Visual ホスティングを使用する場合、ホスト アプリはユーザーから空間入力 (マウスやタッチ入力など) を受け取り、この入力を WebView2 コントロールに転送します。 ビジュアル ホスティングでは、アプリで Windowed ホスティングと同じウィンドウ管理を実行する必要がありますが、次に関する追加のウィンドウ管理要件があります。

  • コンテンツのスケーリング。
  • 空間入力のルーティング (マウス、タッチ、ペンなど)。

コンテンツをスケーリングするための要件

合成ベースのレンダリングでは、WebView2 コントロールは Visual ツリーの一部であるため、既定では、すべての先祖ビジュアルのスケールに基づくスケールでレンダリングされます。 たとえば、WebView2 の先祖の Visual が 2 倍にスケーリング (ズーム) されている場合、WebView2 のコンテンツも 2 倍のスケールでレンダリングされます。 WebView2 の親 Visual が 2 倍にスケーリングされ、その Visual の親も 2 倍にスケーリングされている場合、WebView2 は 4 倍にスケーリングされます。 ただし、WebView2 は独自のコンテンツをスケーリングしていないため、ぼやけています。

これを解決するために、アプリは WebView2 の既定の Visual スケーリングを元に戻し、代わりに Rasterization Scale API を使用して目的の Visual スケーリングを適用できます。 これにより、WebView2 のコンテンツが正しいスケールでレンダリングされます。 「WebView2 の機能と API の概要」の「ラスタライズ スケール」を参照してください。

空間入力をルーティングするための要件 (マウス、タッチ、またはペン)

WebView2 アプリで Visual ホスティングを使用している場合、アプリがそのような入力を管理しない限り、空間入力 (マウス、タッチ、ペンなど) は WebView2 コントロールに送信されません。 入力はアプリの HWNDに送信され、入力の位置が WebView2 を超える場合、アプリはこの空間入力を WebView2 に転送する役割を担います。

アプリは、WebView2 の座標空間への入力位置の必要な変換も担当します。

関連項目:

長所と短所

ビジュアル ホスティングを使用すると、レイアウトをより詳細に制御できます (必要)。 この方法を使用する場合、アプリにはウィンドウ管理とレンダリング API の特定の処理が必要です。

たとえば、ユーザー アクションによって WebView2 の Visual ツリーがスケーリングされる場合、アプリは WebView2 のスケールを調整して、親ビジュアルに対して正しくレンダリングする必要があります。

Visual ホスティング用 API

Visual ホスティング環境で WebView2 を構成するときに使用できる API の一覧については、「WebView2 の機能と API の概要」の「Composition を使用した WebView2 のレンダリング」を参照してください。

互換性と制約

主な互換性の制限事項には、オペレーティング システムとフレームワーク以外のアプリでのレンダリングが含まれます。

オペレーティング システム

WebView2 がサポートされている場所では、すべてのホスティング モードがサポートされます。つまり、Windows 10以降、および特定の Windows Server バージョン。 Windows 7、8、8.1 はサポートされなくなりました。Windows 7 と Windows 8では、Visual ホスティングではなく、ウィンドウ ホスティングのみがサポートされます。

関連項目:

フレームワークの制約

CreateCoreWebView2CompositionControllerWinAppSDK ビジュアルはサポートされていません。つまり、「Visual レイヤーを使用した UI の拡張 (Windows アプリ SDK/WinUI 3)」で説明されている、Microsoft.UI.Composition名前空間内の Visual オブジェクトです。

関連項目

外：