次の方法で共有

High DPIについてのさらなるフォローアップ

  • [アーティクル]

素晴らしい！非常に面白い High DPI の議論です。 Ryanの書いた summary によって議論はますます白熱してきています。ありがとうございます！ --Steven

いくつかの白熱した議論とともに、High DPIに対する多くのコメントが寄せられています。それらの多くは、我々が収集してきたデータと一致する、よい例になっています。私たちがデータを持たない分野に対して、これらのコメントは私たちの持つ多くの仮説を裏付けとなっています。もう一つ明らかになったのは、この機能の一部について誤解があり、またこの機能の理想、可能な事、機能そのものに対してある種の「神話」のような部分も見受けられます。この記事では主にそれら問題の要約と、誤解と思われる部分についての詳細を提供したいと思います。

以下はコメントにて裏付けられた私たちの「仮説」です。

  • ほとんどの人は画面解像度を、文字を大きくするため、またはただの偶然でのみ調整している
  • 一部のコアユーザだけがhigh DPIを知っていて、使用している
  • 一部の人は画面の広さを好み、他の人は大きなUIを好む
  • 一部の人はDPI設定の見つけやすさに対して懸念を持っている
  • アプリケーションの互換性は大きな問題で、一部の人はこれによってこの機能を利用しない
  • IEでのスケーリングはもっとも大きな問題である（IE8をご覧になって多くの修正を確認してください）
  • 多くの複雑かつ微妙な理由で、この機能を多数の人々に説明するのは困難である

また、以下のような混乱もあります。

  • もし全てがベクターベースであったら、これらの問題は全て解決するのか？
  • 開発者が何もしなくても、これらの問題は解決できないのか？
  • アプリケーションによるスケーリングとIEでのズーミングはどう違うのか？
  • DPIは調整の為に必要、それともスケーリングか？

いくつかのトピックについてはコメントでお応えしていますが、これらに対しては関心が高いので、ここで詳細を述べることにしました。

ベクターグラフィックス vs. ラスターグラフィックス

PCにおいて、全てのユーザー、開発者、デザイナーのあらゆるすべての問題を一気に解決する「銀の弾丸」の様な技術がいつも望まれています。それは例えば、この議題の最初記事に対するいくつかのコメントにあったように、もしOSを全てベクターグラフィックスをもとにすればこのスケーリングに関する問題は全て解決するというものです。実際にはすべてをベクターグラフィックスにした場合、いくつかの問題があります。

最初の問題は、アイコンを小さくする時には意味を分かりやすくする為に別の表現方法を用いる方が良い時があるということです。以下のアイコン群を見て下さい。この場合、デザイナーは一番小さなアイコンのデザインでは遠近法を無視したデザインを採用しています。

 

Example of the same icon treated differently depending on size.

この理由ですが、最も小さなアイコンサイズでは、アイコンによって表現される情報は真正面から描いた方がより判りやすい、とデザイナーが感じたからです。このイラストは、この点に関するもう一つの例です：

Additional example of icons treated differently as the size changes.

当然これにより、デザイナーは複数バージョンにイメージデザインを制作しなくてはならず、複雑さは増します。ここでのポイントは、トレードオフが必ず発生し、かつ、そのトレードオフが必ずしも明確にはなっていない事です。

もし、一つのベクターベースのデザインを使用したとしても、デザイナーが思い描いている物を忠実に表わす為に、サイズに依存した微調整が必要である事は共通です。１ピクセルの線で描かれた 128x128サイズのベクター画像を、1/2サイズの64x64に縮小する事を想像してみてください。完璧に1/2ピクセルの線をディスプレイで再現する方法はありません！多くの場合、この点に対する方法として、描画処理は近似した線への“丸め”を行います。しかしながら、この処理を行うと、画像イメージの他の要素のレイアウトが根本的に変更されてしまいます。また、”どの線を丸め処理の対象とするか？”といった疑問もあります。デザイナーが、原版を手動調整していなければ、レンダリングエンジンがその決定を行います。そしてこれが、好ましくない描画結果の要因となります。そこで、どの要素をベクターで使用すべきかのルールを定義すべきである、とよく言われます。しかしそれは、表現可能なコンセプトについて更なる制約を加えてしまうだけです。

Windowsで私たちが使用しているTrueTypeフォントでさえも、その描画結果を可能な限り高品質にする為に、サイズ毎に手動で調整を行っています。TrueTypeのレンダリング パイプラインのほとんどは、アルゴリズムに基づいてベクターソースをスケーリングする事を基本にしていますが、TrueTypeの中には、サイズ毎の“ヒント”が手動でコーディングされています。これはデザイナーが、ある特定の稀なケースをシステムがどのように対処するかを指示する為のものです（例えば、ピクセルの境界にある線をどう対処するか、等）。この点に関するより詳細な記述はこちらをご参照ください： https://blogs.msdn.com/fontblog/archive/2005/10/26/485416.aspx

ベクター画像が、必ずしもより小さなサイズになるという訳ではありません（特に小さな画像）。ほとんどのデザイナーは、描画や画像効果用に多くの複数レイヤーを構成してイメージを作り出すエディタを使用して画像を制作します。ビットマップをベースにした画像では、デザイナーはそれをソフトウェアの一部に追加する前に、予めレイヤーを“フラット化”します。昨今のほとんどのデザイナーは、レイヤーのサイズに対してほとんど気を使いません。なぜなら、フラット化のプロセスでは 基本的にはイメージの解像度に基づいた固定サイズへ変換が行われるからです。ベクター画像には、こうしたフラット化の技術はありませんので、アイコンが大きくなり過ぎない様に、デザイナーは使用するツールと、施す画像効果について慎重に考慮する必要があります。私はWindowsのビットマップのデザイナーが持っているベクター画像の元データを見せてもらいましたが、それは622kでした。もちろん、それは解像度に依存せず同じファイルサイズです。しかし、その巨大なファイルは23kのPNGのビットマップ画像にフラット化されます。

画像作成の工程でサイズの制約事項があったならば、この手動調整を施したベクターベースの画像も小さくなっていたでしょう。しかし、その制約事項はデザイナーへ対する追加の制約事項となったはずですし、その制約事項にうまく対処する方法をデザイナーが学習する必要があったでしょう。

開発者の方々のために

レイアウトやグラフィックを微妙に調節したり、解像度にあわせてイメージの正確にスケールする必要のあるアプリケーションが最良の結果を出すには、アイテムのピクセル位置を正しく指定することが重要です。これは Mac でも、PC でも変わりありません(https://developer.apple.com/releasenotes/GraphicsImaging/RN-ResolutionIndependentUI/ を参照)。適切なツールやフレームワークが提供されていれば、そんな心配はいらないはずだという意見もあります。しかしこうしたツールセットやフレームワークにはそれぞれのトレードオフが存在しています。（それがWin32であっても、.netであっても、HTMLであっても。）これという特効薬はありませんが、開発者が簡単に DPI に対応したアプリケーションを作成できるよう助けることはできます。たとえば、近々重要なエコシステム系のイベントが 2 つ開催されますが、そこで High DPI について詳しくお話しする予定です。また、既存のアプリケーションから DPI対応への変換方法を開発者が習得するための素材も用意しています。1 つめのイベントはMicrosoft Professional Developer Conferenceです。こちらでは “Writing your Application to Shine on Modern Graphics Hardware (link)” と題するトークの中で、High DPI についてお話ししたいと思っています。2 つめのイベントは、Windows Hardware Engineering Conferenceです。こちらでは、“High Fidelity Graphics and Media” トラック (link) の中で high DPI をとりあげる予定です。

アプリケーションの互換性について

アプリケーションの互換性と high DPI に関して、いくつか (bluvg などから) コメントが寄せられています。また、High DPI の設定の複雑さや難解さについてもご意見をいただいています。アプリケーション互換性の問題は、自動スケーリング機能を有効にしたり無効にしたりすることで、回避できる場合があります。この機能は、DPI スケーリング画面 で [カスタム DPI (Custom DPI)] というラベルのボタンをクリックし、[Windows XP 形式の DPI スケーリングを使用する] というチェックボックスをオンまたはオフすることにより変更できます。このチェックボックスがオフになっていると、DPI対応であると宣言していないアプリケーションは自動的にウィンドウ マネージャーによってスケールされます。このボックスがオンになっていると、自動スケーリング機能は無効化されます。DPI 設定 < 144 DPI の場合、このチェックボックスは初期設定でオンになっていますが、DPI設定 >= 144 の場合は初期設定でオフになっています。使用しているアプリケーションや DPI 設定によっては、この初期設定を変更することで、よりよい効果が得られます。また、自動スケーリング機能は、Vista プログラムの互換性プロパティを使用してアプリケーション単位で無効化することもできます。詳細についてはこちらを参照してください。

https://windowshelp.microsoft.com/Windows/en-US/help/bf416877-c83f-4476-a3da-8ec98dcf5f101033.mspx (“Disable Display Scaling on high DPI settings” の項を参照)

DPIスケーリングとアプリケーションごとのスケーリング ( 例 : IEの拡大機能 ) の違い

一般的なアプリケーションUIは、コンテンツ ウィンドウとフレームUIで構成されています。フレームUIは、メニュー項目やツールバー ボタンがあるところです。コンテンツ ウィンドウは、「ドキュメント ビュー」のことです。例えば、IEの場合、コンテンツ ウィンドウは実際のWebページを指します。コンテンツ ウィンドウでHigh DPIスケールをサポートするのに必要なコードは、拡大機能を実装するのに必要なコードと同じです。実際、コンテンツ ウィンドウに対して、IE8では、High DPI設定を使用してデフォルトの拡大機能が構成されています。(詳細については、DPI Scaling and Internet Explorer 8をご参照ください。) しかし、high DPIには、フレームUIのサイズのスケールにも影響を与えます。ほとんどのユーザーがテキストを大きくして読みやすくするためにスケール機能を使用しているので、フレームUIも当然スケーリングされ、メニュー項目やツールバーのヒントのテキストのサイズが変更されます。ここでもしコンテンツ領域のみに適用されるアプリケーションごとのスケールがあったら、アプリケーションはそれもサポートします。開発者はユーザーのニーズに対応するように開発するからです。DPIスケールは、全てのアプリケーションのUIエレメントが同じように表示されるようにします。

DPIは ( “ 1インチが1インチ”となるように ) 画面の調整を目的として使用するべきではないのか？

High DPIは、ディスプレイの違いに関わらずオブジェクトの実際のサイズが同じになるように画面を調整するだけのために使用するべきなのではないか、という意見もありました。論理的な見方をすれば、これは非常に理にかなっています。これは、ディスプレイを “an inch is an inch (1インチは1インチで表示する)” となるように調整する、ということです。私たちはこの対応を検討しましたが、これでは、テキストやUIのサイズを設定できるようにしてほしいというエンドユーザーの要望を満たすことができない、という問題に直面しました。もし別に「グローバル スケール」の変数があるとしたら、アプリケーション開発者は両方のメトリックスを考慮しなければならなくなってしまいます。これでは開発者の作業が複雑になります。さらに、もしユーザーが「UIが小さすぎる」と思った場合、どれくらい大きなUIにすればいいのかは、開発者が決めることなのでしょうか。それともユーザーなのでしょうか。別の言い方をすると、もし設計者が「このボタンは1インチがいい」と思っていても、ユーザーが「ボタンは1.5インチにして使いやすくしたい」と思ったら、誰が設定を決めるべきでしょうか？今日の機能の使用方法を考えると、自分の好きな設定にできるのはユーザーですが、ユーザーの設定が正しく反映されることを確認するのは、アプリケーション開発者の責任です。

繰り返しますが、High DPIに対して高い関心があるのを知ることができ、大変嬉しく思います。確かに、私たちが対処しなければならない問題はありますが、いろいろな意味でエコシステムはこの変化に対応できる時期に来ているようです。今回の記事が、前回の記事に対して寄せられたフィードバックをフォローアップし、High DPI機能の複雑性についてより詳しく説明できていれば幸いです。

--Ryan Haveson