このページの本文へ

Windows Info 第87回

Windows 10+高解像度ディスプレイでのアプリのボケはRS2で解消される【その2】

2017年04月02日 10時00分更新

文● 塩田紳二 編集● ASCII.jp

  • この記事をはてなブックマークに追加
  • 本文印刷

 前回に引き続き、Windows 10の高DPIスケーリングについて解説する。まずは現状のRS1における高DPIスケーリング機能である、「混在モード」について解説する。

高解像度ディスプレーでデバイスマネージャーを開くたびに憂鬱な気持ちにさせられていた文字のボケがRS2では解消される

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スケーリング処理を指定する。指定と効果は以下の通りとなる。

アプリケーション:アプリケーションの描画そのまま(DPI仮想化オフ)
システム:RS1までと同じDPI仮想化による拡大処理(デフォルト値)
システム(拡張):RS2で改良されたDPI仮想化処理

 「アプリケーション」は、GDIアプリケーションではあるが、表示などをユーザーが設定可能であるなど、なんらかの方法で高DPIスケーリングに対応でき、DPI仮想化による処理が不要な場合に指定する。

「アプリケーション」は、GDIアプリケーションにDPI仮想化を適用しない。表示がボケたり、崩れる可能性はないが、高DPI環境化ではウィンドウやダイアログボックスが小さくなりすぎて操作が困難になる可能性がある

 これに対して「システム」は、RS1までと同じ方法でDPI仮想化を処理するものだ。従来のやり方でも問題がない、あるいは、他の方法では問題が出る場合に選択する。実質的にはチェックボックスをオフにしたのと同じである。

「システム」を選択するとRS1までと同じくDPI仮想化によりアプリケーションの描画したウィンドウを拡大して表示する。このとき表示がボケてしまう可能性があるが、ウィンドウなどの大きさが小さくなりすぎる問題は発生しない

 「システム(拡張)」は、RS2で搭載されたDPI仮想化の描画処理を行なう。

「システム(拡張)」は、RS2に実装された描画方法でGDIアプリケーションの表示を拡大する

 RS1まではボケていた表示がシャキッとしたものになる。ただし、アプリケーションによっては、文字が小さくなってしまったり、読みにくくなることもあるようだ。逆にこれは、RS2では描画時にアプリが指定したフォントサイズが変更されている可能性を示す。フォントサイズがGDI内部で変更されていなければ、「アプリケーション」を指定した場合と同じフォントサイズで表示されるはずだからだ。

 同じアプリケーションでも英語版では、正しく動作しているように見えることから、日本語処理に関連する動作の違い(あるいはバグ)の可能性もある。また、記事執筆時点では、RS2はプレビュー版であり、最終的には不具合が修正される可能性もある。

カテゴリートップへ

この連載の記事

注目ニュース

ASCII倶楽部

プレミアムPC試用レポート

ピックアップ

ASCII.jp RSS2.0 配信中

ASCII.jpメール デジタルMac/iPodマガジン