前回に引き続き、Windows 10の高DPIスケーリングについて解説する。まずは現状のRS1における高DPIスケーリング機能である、「混在モード」について解説する。
API経由で有効にするDPIスケーリング混在モード
「DPIスケーリング混在モード」もAPI経由で有効にする機能だ。Windows 8.1で導入されたPer-Display DPI awareアプリケーションでは、dpi値への対応はプロセス単位で行なう必要があった。しかし、たとえばブラウザのプラグインのように、アプリケーションの開発者からみて、サードパーティが開発したソフトウェアを利用するような場合、アプリケーション開発者がプラグインの改良に関われない場合がある。
現在ではアプリケーションの開発の負担を減らすために、アプリケーションは外部の開発者が作成したソフトウェアモジュールをライセンスして呼び出して使う場合が少なくない。
1つのアプリケーション製品でありながら、このように一部のプログラムコードをPer-Display DPI awareにできない場合がある。このような場合、制御が及ばない部分については、DPI unawareとして、Windows側に拡大処理を行なわせるしか方法がない。
しかし、RS1より前のWindowsのDIPスケーリングは、プロセス単位でDIPスケーリングに対応するかどうかしか決定できない。そうなると、制御のおよばないウィンドウが、操作できないほど小さくなってしまうなどの問題があった。
問題は、System DPI awareかどうかの選択をプロセス単位で行なうことにあると言える。これに対してRS1では、SetThreadDpiAwarenessContextというAPIを用意して、スレッドごとにDPIスケーリングの対応を決定できるようにした。
こうすることで、アプリケーションは自分自身をSystem DPI awareとしながらも、改良ができないサードパーティモジュールをDPI unawareとすることで、Windows側のDPI仮想化による拡大表示などをさせることができるようになった。
ただし、この機能もAPIを用いて設定する必要があり、基本的にアプリケーション自体がDPIスケーリングへ対応していなければならず、RS1より前に作られた実行ファイルに関しては何も影響がない。
このようにRS1での改良点には大きなものがある反面、すべてAPI経由で指定する必要があるため、その効果は対応アプリケーションにのみ限られていた。実際にWindowsに添付されているソフトウェアやモジュールの中には、まだDPIスケーリングに対応していないものが存在しており、RS1の導入だけではDPI仮想化に関わる文字のボケが解消されることはなかったのだ。
RS2ではDPIスケーリングがさらに改良された
RS2では、DPI仮想化が行なわれる場合の描画方法が改良された。これにより、従来ボケて表示されていたアプリケーションの表示がスッキリしたものになる。表示の感じからは、描画方法を変更したように思える。
Windows 8で導入されたDPI仮想化は、アプリケーションには従来通り描画を行なわせ、これをデスクトップに描画するときにDPI設定に合わせて機械的に拡大していた。このため、文字の輪郭にあるクリアタイプやアンチエイリアシングの部分も拡大され、全体的にフォーカスの外れた画像のような「ボケ」た表示になっていたわけだ。
これに対してRS2では、描画方法が変わり、アンチエイリアスやクリアタイプの部分が拡大されていない。描画方法、あるいはGDIのエミュレーションの動作が変更になったようだ。
すでに、ボケ文字を表示する標準アプリケーションとしてよく知られる「デバイスマネージャ」などを実行するMMC.EXEや、Windowsの標準組み込みのDPI unawareソフトウェアが対応している。ユーザーがインストールしたアプリケーションにも適応が可能だが、以下に紹介する条件が存在する。
・GDIアプリケーションであること
・アプリの互換性設定で動作モードを手動で設定すること
の2つだ。
まず最初のGDIアプリケーションであることとは、Windows Vista以前のスタイルで作られたデスクトップアプリケーション全般がこれに相当する。別の言い方をするとWPF(Windows Presentation Foundation)を使わないデスクトップアプリケーションだ。なお、UWPやWindowsストアアプリはGDIをまったく利用しないのでGDIアプリケーションにはなりえない(GDI自体、もはや知る必要のない知識ではあるが、逆に知らない人も少なくないとも言えるので)。
Windows 10では、GDIはエミュレーションで専用のサーフェースに描画され、これをDWM(Desktop Window Manager)で合成してデスクトップを作る。従来はサーフェースの作成までは、従来通りで、合成するときに単純拡大していたのだと推測される。
しかしRS2からは、GDIのエミュレーション時に、内部的なパラメーターを変更するなどして、描画する文字のフォントを変更して拡大倍率に応じて描画を行うようになったのだと思われる。このあたり、改造作業が面倒な部分だ。というのも、GDIアプリケーション全部に影響を与えてしまう可能性があり、慎重に行なう必要があるからだ。
その割には、たとえば、100%表示ではもともとボケが発生しないので違いがわからないように、見た目には、何も変わってないようにしか見えないという「地味」な改良点だ。そのせいか、Windows Insider Blogでも何回も取り上げられ、プレビュービルドが出るたびに出される新機能の項目でもDPIスケーリングの進行状況は細かく伝えられてきた。
どれがGDIアプリケーションかを判別する簡単な方法はないが、少なくともWindows XPのタイミングで作られ、その後アップデートされていないソフトウェアはGDIアプリケーションである。
その設定方法だが、エクスプローラーでアプリケーションの実行ファイルを右クリックして「プロパティ」を開く。プロパティダイアログボックスの「互換性」タブを開く。
そこにある「高いDPIスケールの動作を上書きします」という項目のチェックボックスをオンにする。その下のポップアップリストが有効になるので、これでアプリの高DPIスケーリング処理を指定する。指定と効果は以下の通りとなる。
アプリケーション:アプリケーションの描画そのまま(DPI仮想化オフ)
システム:RS1までと同じDPI仮想化による拡大処理(デフォルト値)
システム(拡張):RS2で改良されたDPI仮想化処理
「アプリケーション」は、GDIアプリケーションではあるが、表示などをユーザーが設定可能であるなど、なんらかの方法で高DPIスケーリングに対応でき、DPI仮想化による処理が不要な場合に指定する。
これに対して「システム」は、RS1までと同じ方法でDPI仮想化を処理するものだ。従来のやり方でも問題がない、あるいは、他の方法では問題が出る場合に選択する。実質的にはチェックボックスをオフにしたのと同じである。
「システム(拡張)」は、RS2で搭載されたDPI仮想化の描画処理を行なう。
RS1まではボケていた表示がシャキッとしたものになる。ただし、アプリケーションによっては、文字が小さくなってしまったり、読みにくくなることもあるようだ。逆にこれは、RS2では描画時にアプリが指定したフォントサイズが変更されている可能性を示す。フォントサイズがGDI内部で変更されていなければ、「アプリケーション」を指定した場合と同じフォントサイズで表示されるはずだからだ。
同じアプリケーションでも英語版では、正しく動作しているように見えることから、日本語処理に関連する動作の違い(あるいはバグ)の可能性もある。また、記事執筆時点では、RS2はプレビュー版であり、最終的には不具合が修正される可能性もある。

この連載の記事
- 第382回 タブのウィンドウ間の移動も可能に! Windows Terminal v1.17/v1.18の新機能を見る
- 第381回 WindowsのPowerShellで画像ファイルのExif情報を扱う
- 第380回 Windowsにおける改行文字の扱い
- 第379回 Windows 11で利用頻度が高いプログラムを「簡単に起動」する方法
- 第378回 Windows 10で正式に導入され、11で改良が進んだ「仮想デスクトップ」
- 第377回 Windowsの「デスクトップ」や「ピクチャ」など、「既知のフォルダ(Known Folders)」を使う方法
- 第376回 COM(Component Object Model)は古い技術だが、いまだに現役 あらためて解説する
- 第375回 エクスプローラーのプレビューウィンドウについて解説する
- 第374回 Windows Insider ProgramにCanaryチャンネルが追加されたことで感じるWindows 12の気配
- 第373回 Windows Subsystem for Linuxでsystemdが動くようになったので試した
- 第372回 Windowsにおけるアプリ実行エイリアスとは?
- この連載の一覧へ