WPFの高DPI対応 ── 「DPIに強いはず」なのにぼやける・にじむ原因と対処

「WPF なら DPI 対応は何もしなくていいはずですよね？」という質問を、高DPIがらみの相談の場でよく受けます。半分は正しくて、半分は違います。実際の症状として持ち込まれるのは、「ノート PC 単体ではきれいなのに、会議室の外部モニターにつなぐと画面全体がにじむ」「文字はくっきりしているのにツールバーのアイコンだけぼやける」「一覧の罫線が場所によって太くなったり消えたりする」「画面に埋め込んだ古い帳票コントロールの部分だけ小さい」──どれも「DPI に強いはず」の WPF アプリで現実に起きるものです。

前日の記事「WinForms の高DPI対応」では、Windows の DPI スケーリングの仕組みと DPI 認識モード（Unaware / System Aware / Per-Monitor V2）、そして 96 DPI 直書き時代の WinForms をどう救うかを整理しました。この記事はその WPF 版です。DPI 仮想化や DPI 認識モードの一般論は WinForms 記事に譲り、ここでは「最初から DPI 対応しているはずの WPF で、なぜ・どこに問題が残るのか」という WPF 固有の話に集中します。症状の切り分け、Per-Monitor DPI 対応の宣言方法（.NET Framework 4.6.2 / .NET それぞれ）、単線とビットマップのにじみ対策、WindowsFormsHost 混在の罠、そしてどこまでやるかの判断表まで、実務で使う順に並べます。

この記事で使う用語

DPI 認識モードの一般論は WinForms 記事に譲りますが、本文で断りなく使う語だけ先に押さえておきます。

1. まず結論

まず、この記事全体の骨子となる 3 点です。

• WPF は「起動時の DPI」には最初から正しく追従します。 レイアウト単位が DIP で、描画系がシステム DPI に合わせて自動スケールするため、既定で System DPI Aware です。WinForms のような AutoScaleMode の設定・点検は不要です。²
• それでも残る問題は 4 系統に分かれます。(a) DPI の違うモニターへ移したときの全体のにじみ、(b) ビットマップ画像・アイコンのぼやけ、(c) 単線・罫線のにじみ、(d) WindowsFormsHost / WebBrowser などの混在コンテンツ。原因も直し方も別物なので、まず 3 章の表で切り分けてください。
• WPF 側の作業は「宣言 1 行 + 残りの点検」です。レイアウトの追従はフレームワークがやるので、本当の改修対象はピクセルを直接扱っているコードと、ビットマップ資産と、混在コンテンツだけです（8 章）。

4 系統それぞれの結論は次のとおりです。

なお、DPI 認識モードの一般論（DPI 仮想化、System Aware と Per-Monitor V2 の違い、exe プロパティからの利用者側上書き）と混在 DPI テスト環境の作り方は、WinForms 記事の 2〜3 章・7 章と共通なので本記事では繰り返しません。

この記事の知識マップ

WPFはレイアウト単位がDIPで既定でSystem DPI Awareのため起動時の主モニターDPIには自動で追従するが、System Awareのままだと異なるDPIのモニターへ移した際にOSのDPI仮想化が働き画面全体がにじむ。これを根治するのがPer-Monitor DPI対応で、アプリケーションマニフェストへの宣言だけでウィンドウの再スケーリングがフレームワークにより自動化される。残る改修対象は、UseLayoutRoundingで防ぐサブピクセル配置のにじみ、ベクター資産や複数解像度の切り替えで防ぐビットマップのぼやけ、そしてWriteableBitmapのようなピクセルバッファを自前で扱うコードのOnDpiChangedへの追従に絞られる。WindowsFormsHostやWebBrowserコントロールのようにHWNDを持ち込む混在コンテンツは、Per-Monitor対応の上限を決める要素として別枠で扱う必要がある。

flowchart LR
    accTitle: WPFの高DPI対応の知識マップ
    accDescr: WPFがDIPとSystem DPI Awareによって起動時のDPIには自動追従する一方、異なるDPIのモニター間ではOSのDPI仮想化がにじみを引き起こし、Per-Monitor DPI対応の宣言がそれを防ぐこと、UseLayoutRoundingやベクター資産がそれぞれサブピクセルのにじみとビットマップのぼやけを防ぐこと、WindowsFormsHostやWebBrowserなどHWNDを持つ混在コンテンツがPer-Monitor対応の上限になることを示す図。
    wpf["WPF"]
    per_monitor_dpi_awareness["Per-Monitor DPI対応"]
    dip["DIP(デバイス非依存単位)"]
    system_dpi_aware["System DPI Aware"]
    cross_monitor_blur["モニター間移動時の全体のにじみ"]
    dpi_virtualization["DPI仮想化"]
    app_manifest["アプリケーションマニフェスト"]
    dotnet_framework[".NET Framework"]
    windowsformshost["WindowsFormsHost"]
    hosted_content_scaling_limitation["ホストしたコンテンツのスケーリング制限"]
    windows_forms["Windows Forms"]
    hwnd["HWND(ウィンドウハンドル)"]
    webview2["Microsoft Edge WebView2"]
    webbrowser_control["WebBrowserコントロール"]
    bitmap_blur["ビットマップ画像のぼやけ"]
    vector_graphics_asset["ベクター画像資産"]
    bitmap_scaling_mode["BitmapScalingMode"]
    ondpichanged["OnDpiChanged(DPI変更への追従)"]
    pixel_buffer_code["ピクセルバッファを自前で扱うコード"]
    subpixel_rendering["サブピクセル配置"]
    use_layout_rounding["UseLayoutRounding"]
    snaps_to_device_pixels["SnapsToDevicePixels"]
    textformattingmode_display["TextFormattingMode(Ideal/Display)"]
    wpf -->|"利用する"| dip
    wpf -->|"実装を担う"| system_dpi_aware
    system_dpi_aware -->|"原因になり得る"| cross_monitor_blur
    dpi_virtualization -->|"原因になり得る"| cross_monitor_blur
    per_monitor_dpi_awareness -->|"防止する"| cross_monitor_blur
    per_monitor_dpi_awareness -->|"前提とする"| app_manifest
    per_monitor_dpi_awareness -.->|"前提とする"| dotnet_framework
    windowsformshost -.->|"原因になり得る"| hosted_content_scaling_limitation
    wpf -.->|"利用する"| windowsformshost
    windowsformshost -->|"利用する"| windows_forms
    windowsformshost -->|"前提とする"| hwnd
    hwnd -.->|"原因になり得る"| hosted_content_scaling_limitation
    webview2 -.->|"の後継"| webbrowser_control
    webbrowser_control -.->|"原因になり得る"| hosted_content_scaling_limitation
    dip -->|"原因になり得る"| bitmap_blur
    vector_graphics_asset -->|"防止する"| bitmap_blur
    bitmap_scaling_mode -->|"軽減する"| bitmap_blur
    per_monitor_dpi_awareness -.->|"前提とする"| ondpichanged
    pixel_buffer_code -.->|"前提とする"| ondpichanged
    dip -->|"原因になり得る"| subpixel_rendering
    use_layout_rounding -->|"軽減する"| subpixel_rendering
    snaps_to_device_pixels -->|"軽減する"| subpixel_rendering
    use_layout_rounding -->|"より先に行うべき"| snaps_to_device_pixels
    textformattingmode_display -.->|"用いるのは非推奨"| per_monitor_dpi_awareness

図の実線は常に成り立つ関係、破線は条件付きの関係です(成立条件は詳細ページの各関係の説明に記載)。関係すべての一覧(全24件、根拠・確度つき)と主要概念の定義は知識マップ詳細ページにまとめています。データ: JSON-LD / Turtle

2. WPFはなぜ「DPIに強い」のか ── DIPとSystem DPI Aware

WinForms の高DPI問題の根っこは、座標もサイズも物理ピクセル直書きで、96 DPI 前提のレイアウトを実行時に換算し直す仕組み（AutoScale）を後付けで持っている点にありました。WPF は出発点が違います。XAML に書く Width="120" の 120 は物理ピクセルではなく、1/96 インチを 1 とするデバイス非依存単位（DIP）です。レイアウトは全部この単位で計算され、描画時にシステム DPI に応じた倍率（150% なら 1.5 倍）へ変換されます。文字もベクターフォントとして描画されるため、拡大してもビットマップ的な劣化がありません。この仕組みにより、WPF アプリは何も宣言しなくても System DPI Aware として動作します。²

WinForms との違いを一覧にしておきます。

この表のとおり、WinForms で工数の中心だった「レイアウトが崩れるのを直す」「デザイナー事故を防ぐ」という仕事が、WPF ではほぼ発生しません。「WPF は DPI に強い」は正しい認識です。

ただし、自動なのは System Aware の範囲までです。System Aware とは「サインイン時の主モニターの DPI に合わせる」というモードであって、モニターごとに DPI が違う環境への追従（Per-Monitor）は含みません。また、DIP で拡大されるのはあくまで WPF が自分で描くもの（テキスト、図形、コントロール）で、ビットマップ画像は拡大すればぼやけますし、HWND を持ち込む混在コンテンツは WPF のスケーリングの外側にいます。「DPI に強いはずなのに」という相談は、ほぼこの残りの部分で起きています。

3. それでも起きる問題 ── 症状から原因を切り分ける

相談を受けたとき、当社が最初に使う切り分け表です。WPF では症状と原因の対応が WinForms よりさらにきれいに分かれるので、この表だけで原因がほぼ特定できます。

1 行目の「全体が一様ににじむ」について補足します。これは WinForms 記事の 2 章で書いた DPI 仮想化（OS のビットマップ拡大）が System Aware アプリに対して働いている状態で、アプリが壊れているわけではありません。System Aware のアプリは「サインイン時の主モニターの DPI」で描画し、それ以外の DPI のモニターでは OS が拡大・縮小して帳尻を合わせます。レイアウトは崩れない代わりににじむ、という OS の救済措置です。² 直すとは、この救済を断って「モニターごとの DPI に自分で追従します」と宣言すること、つまり Per-Monitor 化です。

逆に 3 行目以降の症状は、System Aware のままでも直せます。「マルチモニター運用はないが、150% の画面でアイコンと罫線が汚い」という相談なら、4 章を飛ばして 5 章から着手して構いません。

3.1 手元で症状を再現・確認する手順

この記事には画面キャプチャを掲載していません。にじみ・ぼやけは静止画で見せるより、手元の実機で再現させたほうが確実に分かります。次の手順で、上の表の症状を自分の目で確認してください。混在 DPI のテスト環境そのものの作り方は WinForms 記事の 7 章にありますが、モニター 1 枚でもここまでは確認できます。

1. 拡大率を変える。 スタート > 設定 > システム > ディスプレイ >「拡大縮小とレイアウト」>「テキスト、アプリ、その他の項目のサイズを変更する」で 100% / 125% / 150% を切り替えます。⁸ 効果がいちばん出るのは 125% と 150% です（非整数倍だから、というのが 4.1 節の話です）。
2. アプリを起動し直す。 WPF は既定で System Aware なので、起動中のアプリは新しい拡大率に追従しません。変更後は必ず起動し直してください。それでも直らない場合はサインアウト・サインインまで行います（System DPI はサインイン時に固定されるためです）。
3. 拡大鏡で細部を見る。 Windows ロゴキー + +（プラス）で拡大鏡が起動します。⁹ 400% 程度まで上げて、次の 3 か所を順に見ます。
   • 罫線・枠線 ── 線の片側または両側に薄いグレーが 1px はみ出していれば、5.1 節のサブピクセル配置です。同じ 1 指定の線なのに、行によって濃さや太さが違って見えるのが決定的なサインです。
   • アイコン・画像 ── 輪郭が二重ににじみ、本来 1px であるべき線が 2px 分の中間色になっていれば、5.3 節のビットマップ補間拡大です。同じ画面の文字がくっきりしていることが切り分けの決め手になります（文字はベクターなのでぼやけません）。
   • 画面全体 ── 文字も罫線もアイコンも等しくぼやけていれば、個別の描画の問題ではなく OS の DPI 仮想化です。この場合は 4 章へ進みます。
4. モニター間を移動させる（2 枚以上ある場合）。 拡大率の違うモニターへウィンドウをドラッグします。移した先でにじみ、元へ戻すと直るなら、表の 1 行目です。逆に、移動しても見え方が変わらないなら (a) は起きていません。
5. 実行中に拡大率を変える。 アプリを起動したまま 1. の設定を変更します。System Aware のアプリは、その場でにじみます。

この 1〜5 は、Per-Monitor 化した後の点検手順としてもそのまま使えます。公式の推奨テスト項目も、モニター間の移動・異なる DPI での起動・実行中の拡大率変更・主モニターを入れ替えてのサインアウト/サインインの 4 点です。¹

4. マルチモニターのにじみ ── Per-Monitor DPI対応

4.1 System Awareの限界

System DPI はサインイン時に主モニターの DPI で固定されます。150% のノート内蔵ディスプレイが主モニターなら、WPF は全ウィンドウを 1.5 倍で描き、100% の外部モニターへ移すと OS が 2/3 に縮小表示します。この OS スケーリングは非整数倍のときに特にぼやけて見えます。² 200% と 100% の 2 倍差よりも、125% と 150% のような中途半端な組み合わせのほうが見た目の劣化が大きい、というのは検証してみると実感できます。

つまり System Aware の WPF で困るのは、DPI の違うモニターを行き来する使い方と、サインイン後にスケーリング設定が変わる状況（ドッキングステーションの抜き差しで主モニターが変わる、RDP でクライアント側の DPI が持ち込まれる、など）に限られます。全員が単一モニターの固定デスクトップで使う社内アプリなら、System Aware のままで実用上完結します。この判断は 8 章の表に戻ってきます。

4.2 .NET Framework 4.6.2以降での宣言方法

WPF の Per-Monitor DPI 対応は .NET Framework 4.6.2 で入りました。³ それ以前は、OS へ Per-Monitor を宣言しても WPF 側が DPI 変更に追従してくれず、ウィンドウの再スケーリングを全部自前で書く必要がありました（Windows 8.1 時代のサンプルがネイティブヘルパー DLL を使う大掛かりな作りだったのはこのためです）。4.6.2 以降は WPF が WM_DPICHANGED を処理し、ウィンドウサイズの調整・再レイアウト・再描画まで自動で行います。

要件は 2 つ、Windows 10 Anniversary Update（1607）以降の OS と、.NET Framework 4.6.2 以降をターゲットにしたビルドです。⁴ 宣言はアプリケーションマニフェストに書きます。

<asmv3:application xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">
  <asmv3:windowsSettings>
    <!-- .NET Framework 4.6.2〜4.7.2 は PerMonitor 単独で宣言する（開発者ガイドと同じ）。
         WPF の PerMonitorV2 サポートは .NET Framework 4.8 以降のため、
         4.8+ / .NET では「PerMonitorV2, PerMonitor」と V2 を先頭に置く -->
    <dpiAwareness xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings"
      >PerMonitor</dpiAwareness>
    <!-- dpiAwareness を認識しない古い OS 向け（System Aware にフォールバック） -->
    <dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true</dpiAware>
  </asmv3:windowsSettings>
</asmv3:application>

この 2 段構えには意味があります。dpiAwareness 要素は Windows 10 1607 以降で認識され、カンマ区切りで並べた値のうち最初に認識できたものが使われます。¹⁰ dpiAwareness 要素自体を知らない古い OS では dpiAware の宣言（System Aware）にフォールバックする、という寸法です。

ここで PerMonitor と PerMonitorV2 をターゲットフレームワークで使い分ける点に注意してください。WPF が PerMonitorV2（と Mixed-Mode DPI）を正式にサポートするのは .NET Framework 4.8 以降で¹¹、4.6.2 の開発者ガイドのサンプルも PerMonitor 単独の宣言です。⁴ 4.6.2〜4.7.2 ターゲットで V2 を先頭に書くと、Windows 10 1703 以降の OS はフレームワークが対応していない V2 モードを選んでしまい、特に WindowsFormsHost などの混在コンテンツ周りで想定外の動きになります。4.8 以降（および .NET の WPF）に上げてから PerMonitorV2, PerMonitor と V2 を先頭に置き、タイトルバー・スクロールバーなど非クライアント領域のスケーリングを OS に任せる（WinForms 記事の 3 章参照）のが当社のおすすめです。

1 点、ターゲットフレームワークの罠があります。実行環境の .NET Framework が 4.6.2 以降でも、プロジェクトのターゲットが 4.6.1 以前のままだと Per-Monitor 追従は既定で無効です。この場合は app.config の AppContext スイッチで明示的に有効化します。⁴

<configuration>
  <runtime>
    <!-- 二重否定に注意: 「DPI変更でスケールしない」を false にする＝有効化 -->
    <AppContextSwitchOverrides value="Switch.System.Windows.DoNotScaleForDpiChanges=false"/>
  </runtime>
</configuration>

「マニフェストを書いたのに動かない」という問い合わせの原因は、経験上ほぼこのターゲットフレームワークか、マニフェストがビルドに含まれていない（プロジェクト設定で既定マニフェストのままになっている）かのどちらかです。

4.3 .NET (Core 3.1〜.NET 8) での宣言方法

.NET 上の WPF も、マニフェストなしの既定は System Aware のままです。WinForms がプロジェクトファイルの ApplicationHighDpiMode や Application.SetHighDpiMode という専用の入り口を持つのに対し、WPF にはコードやプロジェクト設定から DPI 認識モードを切り替える公式の仕組みがありません。宣言方法は .NET Framework と同じです。

マニフェストの追加手順も画面キャプチャなしで書けるので、メニュー名をそのまま並べます。

1. ソリューションエクスプローラーでプロジェクトを右クリックし、「追加」>「新しい項目」（ショートカットは Ctrl+Shift+A）を選びます。
2. 一覧から「アプリケーション マニフェスト ファイル」テンプレートを選び、既定の名前 app.manifest のまま追加します。
3. 追加された app.manifest を開き、4.2 節と同じ dpiAwareness 宣言を <asmv3:application> 要素として書きます。テンプレートには requestedExecutionLevel（UAC の要求レベル）などが最初から入っているので、それらは消さずに追記してください。
4. プロジェクトファイルの <PropertyGroup> に <ApplicationManifest>app.manifest</ApplicationManifest> を書いて参照させます（SDK スタイルのプロジェクトでは、app.manifest という名前で追加すれば自動的に認識されることもありますが、明示しておくほうが確実です）。

.NET Framework のプロジェクトの場合は 4. の代わりに、プロジェクトのプロパティ >「アプリケーション」タブ >「マニフェスト」のドロップダウンで追加したマニフェストを選びます。

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>WinExe</OutputType>
    <TargetFramework>net8.0-windows</TargetFramework>
    <UseWPF>true</UseWPF>
    <ApplicationManifest>app.manifest</ApplicationManifest>
  </PropertyGroup>
</Project>

ランタイムが新しいので 4.2 節の AppContext スイッチは不要です。「.NET に移行すれば高DPIも自動で解決」とはならない点だけ注意してください。移行で楽になるのは WinForms 側の話で（WinForms 記事 4.1 節）、WPF は .NET Framework 4.6.2 の時点で今と同じ水準に達しています。

宣言後にやることが残っているのは WinForms と同じですが、中身が違います。WinForms ではレイアウト崩れの改修が主戦場でした。WPF ではレイアウトはフレームワークが追従してくれるので、残るのは全画面の表示点検と、ビットマップ資産の DPI 切替（5.3 節）、ピクセルを直接扱うコードの追従（6 章）、混在コンテンツの確認（7 章）です。画面数が同じなら、Per-Monitor 化の総工数は WinForms より一回り小さく済むのが通例です。

5. 描画のにじみ・ぼやけ ── 単線・文字・ビットマップ

この章の内容は Per-Monitor 化と独立です。System Aware のままでも効くので、マルチモニター運用のないアプリでも適用する価値があります。

5.1 単線・罫線のにじみ ── UseLayoutRoundingとSnapsToDevicePixels

DIP でレイアウトするということは、要素の境界が物理ピクセルの整数位置に乗るとは限らないということです。125% なら 1 DIP = 1.25px なので、幅 1 DIP の罫線は物理ピクセル 1.25 個分に相当し、ピクセルの中間に落ちたエッジはアンチエイリアスで半透明に描かれます。結果が「線がにじむ」「同じ 1px 指定なのに行によって太さが違って見える」です。96 DPI でも、Grid の星付きサイズ（*）の割り算や中央揃えの余白計算で 0.5px に乗れば同じことが起きます。これは WPF のサブピクセル描画の仕様であって、DPI 問題というより「DPI が上がると露見しやすくなる」問題です。⁶

第一手はレイアウト丸めです。ルート要素に 1 行足します。

<Window x:Class="MyApp.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        UseLayoutRounding="True">

UseLayoutRounding はレイアウトパスで非整数のピクセル値を丸める仕組みで、既定は無効、ルートに設定すればビジュアルツリー全体へ伝播します。⁶ 似た名前の SnapsToDevicePixels は役割が違い、レイアウトではなく描画時にエッジをピクセル境界へスナップします。こちらも既定は false で、設定はサブツリーへ継承されます。96 DPI を超える環境で単線周辺のアンチエイリアスによるにじみを抑える用途が公式ドキュメントにも挙げられています。⁷

迷ったら「ルートに UseLayoutRounding="True"、それでも残る箇所に SnapsToDevicePixels="True"」の順です。丸めの副作用として、星付きサイズで等分していた列幅が 1px 単位で不均等になることがありますが、業務アプリの画面で問題になった経験はほとんどありません。なお DrawingContext で自前描画しているコードのにじみには GuidelineSet という低レベルの手段もありますが、まず描画座標を丸めるだけで大半は解決します。

5.2 文字のにじみ ── TextFormattingMode

「WPF は文字が薄い・にじむ」という昔からの不満は、DPI というよりテキスト整形モードの話です。WPF のテキスト整形には、フォント本来の理想メトリクスで配置する Ideal（既定）と、GDI 互換メトリクスで配置する Display の 2 モードがあります。¹² Ideal は文字間隔が美しくスケーリングにも素直ですが、96 DPI（100%）で小さめの文字を描くとアンチエイリアスでにじんで見えることがあります。TextOptions.TextFormattingMode="Display" をルートに設定すると WinForms 的なくっきり感になります。

ただし高DPI環境では話が逆になります。Display は 96 DPI のピクセル格子に合わせる整形なので、スケーリング下ではかえって品質が落ちることがあります。100% 環境の利用者が多いなら Display、125% 以上が主流になった今の標準環境では既定の Ideal のまま、が実務的な割り切りです。100% のときだけ Display に切り替える実装も可能ですが、そこまでやる価値がある画面（テキストエディター的な画面）は限られます。

5.3 画像・アイコンのぼやけ ── ベクター優先と複数解像度

WPF は Image に指定したビットマップも DIP で配置し、DPI に応じて拡大します。16×16px のアイコンは 150% 環境では 24×24px に補間拡大され、既定の補間アルゴリズム（Linear）ではっきりぼやけます。⁵ 「文字はきれいなのにアイコンだけ眠い」という WPF アプリの見た目は、ほぼ全部これです。

対策は優先順で 3 つあります。

1. ベクター資産にする（第一候補）。Path / Geometry / DrawingImage で持つアイコンはどの DPI でもくっきり描画され、切替コードも不要です。デザインツールや SVG からの XAML 変換ツールも充実しています。新規アプリのアイコンは最初からベクターで持つ、を規約にする価値があります。Segoe MDL2 Assets などのアイコンフォントも同じ効果です。
2. 複数解像度のビットマップを DPI で切り替える。写真やスクリーンショットなどベクター化できない資産は、96 / 120 / 144 / 192 DPI 向け（16 / 20 / 24 / 32px など）を用意し、現在の DPI に応じて選びます。公式の開発者ガイドも、ぼやけ対策として DPI ごとの資産切替を推奨しています。²
3. RenderOptions.BitmapScalingMode で補間を選ぶ。資産を増やせない場合の緩和策です。200% のような整数倍なら NearestNeighbor でドットのまま拡大するほうがくっきりし、大きい画像の縮小には HighQuality（Fant）が向きます。⁵

2 の切替は、Per-Monitor 対応済みなら OnDpiChanged（.NET Framework 4.6.2 以降で利用可）で行います。

public partial class MainWindow : Window
{
    protected override void OnDpiChanged(DpiScale oldDpi, DpiScale newDpi)
    {
        base.OnDpiChanged(oldDpi, newDpi);
        // モニター間移動やスケーリング変更のたびに呼ばれる
        AppIcon.Source = IconAssets.SelectFor(newDpi.DpiScaleX);
    }
}

public static class IconAssets
{
    // 16 / 24 / 32 px で用意した資産から拡大率に合うものを選ぶ
    public static BitmapImage SelectFor(double scale) => scale switch
    {
        <= 1.0 => Load("icon16.png"),
        <= 1.5 => Load("icon24.png"),
        _      => Load("icon32.png"),
    };

    private static BitmapImage Load(string name) =>
        new(new Uri($"pack://application:,,,/Assets/{name}"));
}

System Aware のままなら DPI は起動後変わらないので、起動時（Loaded）に VisualTreeHelper.GetDpi(this) で一度選ぶだけで済みます。切替コードを書く前に、「そもそもこの資産はベクターにできないか」を毎回問い直すのが、結局いちばん保守が楽です。

6. ピクセルを扱うコードとDPI変更への追従

WPF の自動スケーリングの傘の外に出るのが、物理ピクセルを自分で数えるコードです。典型は次の 3 つで、どれも「開発機（100%）では完璧、客先の 150% でだけぼやける・ずれる」という嫌な出方をします。

1 つめは WriteableBitmap / RenderTargetBitmap などピクセルバッファを自前で作るコードです。ピクセル数を DIP のサイズと同じ値で作ると、150% 環境では 1.5 倍に補間拡大されてにじみます。現在の DPI は VisualTreeHelper.GetDpi が返す DpiScale 構造体で取れるので、ピクセル数は物理ピクセルで、DPI はバッファに正しく焼き込みます。

// imageHost: 描画結果を表示する要素（ActualWidth/Height は DIP）
DpiScale dpi = VisualTreeHelper.GetDpi(imageHost);
int pixelWidth  = (int)Math.Ceiling(imageHost.ActualWidth  * dpi.DpiScaleX);
int pixelHeight = (int)Math.Ceiling(imageHost.ActualHeight * dpi.DpiScaleY);

// 96,96 固定で作らず、実際の DPI を渡す（1 物理ピクセル = 1 バッファピクセルになる）
var bitmap = new WriteableBitmap(
    pixelWidth, pixelHeight,
    dpi.PixelsPerInchX, dpi.PixelsPerInchY,
    PixelFormats.Bgra32, null);

2 つめはスクリーン座標や Win32 相互運用です。PointToScreen が返す座標、WM_MOUSEMOVE やフックで受け取る座標、MoveWindow に渡す座標はすべて物理ピクセルで、XAML 側の DIP と混ぜると 125% 環境で 1.25 倍ずれます。変換は CompositionTarget の行列を使います。

var source = PresentationSource.FromVisual(this);
if (source?.CompositionTarget is { } target)
{
    // DIP → 物理ピクセル
    Point device = target.TransformToDevice.Transform(new Point(x, y));
    // 物理ピクセル → DIP
    Point dip = target.TransformFromDevice.Transform(devicePoint);
}

3 つめはキャッシュです。DPI を織り込んで作ったビットマップ・レイアウト値・フォーマット済みテキストをキャッシュしている場合、Per-Monitor 化するとモニター間移動のたびに陳腐化します。5.3 節と同じく OnDpiChanged（またはウィンドウの DpiChanged イベント）で作り直してください。ここでも System Aware のままなら DPI は起動時に固定なので、追従コードは不要です。「Per-Monitor 化のコスト＝ピクセルを扱っているコードの数」と考えて見積もると、実態とよく合います。

なお、こうした再生成処理を非同期でやる場合の UI スレッドの扱いは「WPF/WinForms の async と UI スレッド」で整理したとおりです。

7. 混在コンテンツの罠 ── WindowsFormsHost・WebBrowser・サードパーティ

WPF の自動スケーリングが及ぶのは、WPF が自分で描くものだけです。HWND を持ち込む要素は WPF の描画の「外」にあるため、DPI の扱いが一段ややこしくなります。Windows の公式資料でも、「WPF に載せた他フレームワーク、他フレームワークに載せた WPF は自動ではスケールしない」と明記されています。¹

実務でいちばん多いのは 1 行目です。「WPF に移行したが、帳票プレビューやグラフだけ古い WinForms / ActiveX コントロールを WindowsFormsHost で載せている」という構成のアプリを Per-Monitor 化すると、WPF 部分は完璧に追従するのに、ホストの中だけが移動後の DPI に追従せず、小さいまま・粗いままになります。Win32 レベルには混在 DPI をホストする仕組み（SetThreadDpiHostingBehavior）もありますが、WPF から気軽に使えるものではなく、当社では「混在部分が Per-Monitor 対応の上限を決める」と割り切って、先に混在コンテンツの一覧を作ることから始めます。混在をなくす方向の判断材料は「WinForms / WPF / WinUI をどう選ぶか」と「ActiveX/OCX を維持するか、ラップするか、置き換えるか」にまとめてあります。

8. どこまでやるか ── 判断表と段階的な進め方

WPF の場合、選択肢は実質 2 つです（WinForms のような「何もしない＝Unaware」は、宣言しなくても System Aware なので存在しません）。

判断軸は WinForms 記事 7 章と同じ（アプリの寿命・利用環境・改修予算）ですが、WPF は Per-Monitor 化の限界コストが小さい点が違います。宣言は 1 ファイル、レイアウトはフレームワークが追従、残作業はピクセル系コードと資産の数に比例。混在コンテンツが少ないアプリなら、Per-Monitor まで行く費用対効果は WinForms よりはっきり高いです。当社が実際の案件でおすすめしている進め方は次の 3 段階です。

1. System Aware のままの品質改善: ルートへの UseLayoutRounding、アイコンのベクター化・複数解像度化、WriteableBitmap 系の DPI 修正。マルチモニターのにじみ以外はここで全部解消し、Per-Monitor 化しない判断をした場合もそのまま資産になります。
2. Per-Monitor 宣言と点検: マニフェストを追加し、混在 DPI 環境で全画面を回して問題箇所を洗い出します。ここで見つかる問題は 5〜7 章のどれかに分類できるはずです。
3. DPI 変更への追従実装: OnDpiChanged での資産切替・キャッシュ再生成。混在コンテンツはこの段階で「どこまで許容するか」を決めます。

テスト環境は WinForms 記事 7 章に書いた構成（スケーリングの違うモニター 2 枚、主モニター入替＋再サインイン、実行中のスケーリング変更、高DPIクライアントからの RDP）がそのまま使えます。¹ WPF で重点的に見るべきは、非整数倍（125% / 150%）での罫線・アイコン・自前描画と、モニター間をまたいでウィンドウをドラッグしたときの挙動です。利用環境の分布（何 % のユーザーがマルチモニターか）を先に把握しておくと投資判断がぶれません。この観点は「Windows アプリ UX 設計」でも書きました。

9. まとめ

WPF は DIP と自動スケーリングにより最初から System DPI Aware で、WinForms の主戦場だった「レイアウト崩れとの戦い」はほぼ存在しません。それでも残る問題は 4 系統──マルチモニターのにじみ（Per-Monitor 未対応）、ビットマップのぼやけ、単線のにじみ、混在コンテンツ──で、それぞれ対処が確立しています。

• マルチモニターのにじみは、.NET Framework 4.6.2 以降 / .NET の WPF ならマニフェスト宣言だけで Per-Monitor 追従が自動で手に入る
• 単線・罫線はルートの UseLayoutRounding="True" が第一手、残りに SnapsToDevicePixels
• アイコンはベクター資産を第一候補、ビットマップは複数解像度＋DPI 切替
• WriteableBitmap やスクリーン座標などピクセルを扱うコードだけが本当の改修対象。その数が Per-Monitor 化の工数を決める
• WindowsFormsHost / WebBrowser / サードパーティが対応の上限を握る。先に棚卸しする

「WPF だから大丈夫なはず」で止まっていたアプリも、この整理で見れば直す場所は数えるほどしかないことが多いです。手元のアプリがどこまで直せるか、混在コンテンツを含めた現状調査や対応レベルの判断に迷う場合はお手伝いできます。

関連記事

• WinFormsの高DPI対応 ── 4Kモニターでぼやける・崩れる原因と現実的な対処
• WinForms/WPF/WinUIの選び方 - 実務判断表
• WPF/WinFormsのasyncとUIスレッドを一枚で整理
• WindowsアプリUX設計 - 利用環境別の優先順位

関連する相談領域

合同会社小村ソフトでは、WPF / WinForms アプリの高DPI対応（現状調査、Per-Monitor 化の可否判断、混在コンテンツの棚卸しと改修）、PC 入れ替え・4K モニター導入に伴う表示不具合の原因調査、UI 刷新の相談を扱っています。

• 技術相談・設計レビュー
• Windowsアプリ開発
• 既存資産活用・移行支援
• お問い合わせ

参考リンク

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

WPFはDPI対応が不要と聞きましたが、なぜにじむのですか？

WPFはレイアウト単位が1/96インチのデバイス非依存単位（DIP）で、既定でSystem DPI Awareとして動くため、起動時の主モニターDPIには正しく追従します。しかしSystem DPIはサインイン時に固定されるため、DPIの違うモニターへウィンドウを移すとOSがウィンドウ全体をビットマップ拡大・縮小して帳尻を合わせ、全体が一様ににじみます。特に125%と150%のような非整数倍の組み合わせで劣化が目立ちます。根治はマニフェストでPer-Monitor DPI対応を宣言することで、.NET Framework 4.6.2以降のWPFならウィンドウの再スケーリングは自動で行われます。

WPFで1pxの罫線がにじむ・太さが揃わないのはなぜですか？

DIPでレイアウトするため、要素の境界が物理ピクセルの整数位置に乗るとは限らないからです。125%環境では1 DIP = 1.25pxとなり、ピクセルの中間に落ちたエッジはアンチエイリアスで半透明に描かれてにじみます。第一手はルートWindowにUseLayoutRounding="True"を設定することで、レイアウトパスで非整数のピクセル値が丸められ、ビジュアルツリー全体へ伝播します。それでも残る箇所には描画時にエッジをピクセル境界へスナップするSnapsToDevicePixels="True"をピンポイントで適用します。どちらも既定は無効です。

WPFで文字はきれいなのにアイコンだけぼやけるのはなぜですか？

文字はベクターフォントとして描画されるためどのDPIでもくっきりしますが、ビットマップ画像はDIPで配置されてDPIに応じて補間拡大されるためです。16×16pxのアイコンは150%環境で24×24pxに拡大され、既定の補間（Linear）でぼやけます。対策の優先順は、(1) Path/Geometry/DrawingImageやアイコンフォントなどベクター資産にする、(2) 複数解像度のビットマップを用意してVisualTreeHelper.GetDpiやOnDpiChangedでDPIに応じて切り替える、(3) RenderOptions.BitmapScalingModeで補間アルゴリズムを調整する、です。

WPFのPer-Monitor対応はどう設定しますか？

アプリケーションマニフェストにdpiAwareness要素を書いて宣言します。WinFormsのApplicationHighDpiModeのようなプロジェクト設定やコードからの切り替え手段はWPFにはありません。要件はWindows 10 1607以降のOSと.NET Framework 4.6.2以降のターゲットで、宣言すればWM_DPICHANGEDの処理からウィンドウの再スケーリングまでフレームワークが自動で行います。WPFのPerMonitorV2サポートは.NET Framework 4.8以降なので、4.6.2〜4.7.2ではPerMonitor単独で宣言します。ターゲットが4.6.1以前のままだと追従が無効のため、AppContextスイッチでの有効化が必要です。なおElementHostやHwndSourceに載せられたWPFのPer-Monitor動作は公式にサポート外です。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。