マイクロソフトのEngineering Windows 7 ブログ : Graphics

Windows 7 での ClearType の技術的な変更点

e7blog — Mon, 20 Jul 2009 12:51:22 GMT

Bill Gates が持っている数多くの情熱のうちの 1 つは読むことであり、PC 上で読むことを快適なエクスペリエンスにするという彼の望みは、長年にわたり続けられてきた取り組みです。1998 年の COMDEX で、Bill Gates は ClearType を発表しました (こんなにも昔のことだったなんて、信じられません)。発表時、LCD モニターを持っていた人はごくわずかで、15 インチの 1024x768 モニターが数千ドルもしました (今だと 100 ドルもしないようなもの)。スムージングやアンチエイリアシングという概念はずいぶん前から存在しており、タイポグラフィ (文字体裁) やアニメーション、ゲームの世界では一般的なものです。ClearType は LCD パネルの特性を基盤として、これを新たなレベルに引き上げました。ClearTypeはその後 Windows XPに搭載され、Vista と Windows 7 にも引き続き入っています。リリースごとに、基礎となるテクノロジー、それをサポートするフォント、および開発者が利用できる API が変更されてきました。ユーザーの中には、ClearType で表示した画面をそれほど良いと思わず、この機能を無効にしたいと考える人々もいることが長年の間に判明しています。私たちはこれを認識しており、適切なコントロールを提供できるようにしたいと考えています。ClearType は Windows プラットフォームの一部でもあり、アプリケーションの開発者が呼び出してコントロールできる API を提供しています。ClearType は「視覚的な好み」であるという従来からの見方があり、この投稿でも好みと言える一面があることを紹介したいと思います。しかし、アプリケーションによって使用される API であるという一面、つまり、アプリケーションが必要に応じてフォント、色、その他の属性を選択できるのと同じである、ということについても説明したいと思います。この投稿では、歴史や背景を交えながら Windows 7 での実装の詳細に踏み込んで説明します。Greg Hitchcock は ClearType の開発リーダーで、開発当初から担当しています。 また、Windows 7エンジニアリング チームで在職期間が最も長いメンバーのうちの 1 人です。彼より Microsoft での在職期間が長い同僚はたったの 6 人しかおらず、そのうちの 1 人は Larry です!

--Steven

フィードバックに基づき、Windows 7 におけるフォントレンダリングのしくみを明確にし、ClearType フォントレンダリングが、どのような経緯で Windows のデフォルトとして選ばれたのかについて説明します。ClearType が好きではなく、システムのデフォルト設定を Windows Me でデフォルトだった 2 階調のレンダリングに変更したいときは、次のステップを実行します。

[スタート] メニューの [検索] で「視覚」と入力する
コントロールパネルから [Windows のデザインとパフォーマンスの調整] を選択する
カスタムオプションの下で、[スクリーンフォントの縁を滑らかにする] をオフにする

この投稿でこれから説明するより詳しい答えは、デフォルトの設定を変更しても「白黒」のようにはっきり認識できるわけではないことをご説明します。お気付きのように、Windows 7 のコントロールパネルには新しい ClearType チューナーも含まれており、レンダリングを詳細にコントロールすることができます。これについても、この後で詳しく説明します。

ClearType

ClearType は、フォントレンダリングのデザインおよびコンピューターディスプレイで読むことのパフォーマンスの両方を向上させるために開発されたテクノロジです。ほとんどのユーザーがコンピューターでの作業の 80% 以上を画面を読むことに費やしているため、この分野における向上は Windows の全体的なエクスペリエンスの大幅な向上につながります。ClearType テクノロジは絶えず進化しており、E7 ブログの以前の投稿で説明したように、最新の変更は Windows 7 に盛り込まれました。

簡単に説明すると、ClearType は、ディスプレイの色付きのサブピクセルの基になるジオメトリを完全なピクセルであるかのように使用することにより機能します。それによって、より優れた解像度を得ると同時に、色の影響の認識を排除するために人間の視力の原理を使用しています。テクノロジの詳細および人間の視覚的な認識をどのように利用しているかは、こちらで説明されています。具体的には、ClearType テクノロジは、赤、緑、青 (RGB) が垂直方向に並べられているサブピクセルを備えた LCD に対して最適化されていますが、CRT ディスプレイ (特にアパーチャグリル形式のもの) や RGB が水平方向に並んでいる LCD でも十分に機能します。これは直観に反しているように思えるかもしれませんが、非公式な研究の結果、ユーザーの約 70% がこれらの最適でないディスプレイでも ClearType を好むことがわかりました。他のレンダリング技法を好んだ 30% のユーザーにとって、これらの最適でないディスプレイにおける ClearType に関する最大の懸念事項は、テキストコントラストの損失でした。

Windows のほかの種類のフォント レンダリング

多くのディスプレイ方式、さまざまなユーザーや視覚体系が混在する中で、私たちはどのような経緯で Microsoft Windows に ClearType を実装することにしたのでしょうか? Microsoft は、がむしゃらに ClearType をデフォルトのレンダリングにしようとしたわけではありません。テクノロジは、2000 年に Windows CE 製品で初めてリリースされました。Windows CE 環境は通常、使用されるハードウェアが十分にコントロールされているため、ClearType が各デバイス上で適切に機能するか容易に検証でき、画面の読み取りエクスペリエンスを最適化するために ClearType またはハードウェアを調整することも簡単でした。Windows プラットフォームでの ClearType の最初のリリースは 2001 年の Windows XP でした。

2 階調レンダリング

2 階調レンダリングの例。ブラウザによってこの画像が拡大/縮小されている場合、テキストが正しく表示されない場合があるのでご注意ください。

Windows XP より前では、2 種類のフォントレンダリングが Windows でサポートされていました。まず 1 つ目は 2 階調レンダリングですが、「白黒」レンダリングという呼び方の方が一般的かもしれません。エイリアスされたテキストと呼ばれることもあります。2 階調レンダリングでは、2 つの色 (前景色および背景色) でフォントを表します。これは Windows 3.1 がリリースされた時に TrueTypeによってサポートされていた最初の種類のレンダリングですが、Windows 1.0 からのビットマップ形式のフォントを表示するために欠かせない方法でもありました。2 階調レンダリングは、特に TrueType のようなアウトラインテクノロジから生成された場合は、画面の解像度が低いと、最適化が非常に困難です。2 階調で最良の品質を得るためには、TrueType フォントのヒンティングに相当の労力をかける必要があります。レンダリングの詳細をこのレベルに持ってくるには、ベテランでも 1 つのフォント当たり 6 か月から 1 年近くヒンティングに時間がかかるのが普通です。4 種類のフォントファミリなら 4 倍になります。一部のシステムフォントのように、文字セットがより大きい場合は、さらに長くかかる可能性もあります。

フォントのスムージング / グレースケール

レンダリングの 2 つ目の形式は、フォントスムージングとして知られています。Windows 2000 のデフォルトのレンダリングになり、Windows 95 のオプションとして Plus! パックで初めてリリースされました。フォントスムージングは、従来のアンチエイリアシング技法のフォントのコントラストを向上させることを目指したハイブリッドグレースケールアンチエイリアシング技法です。従来のテキストアンチエイリアシングとフォントスムージングを差別化するのには、2 つの要素があります。

まず、従来のアンチエイリアシングは、フォントアウトラインデータを拡大してから、ダウンサンプリングすることにより機能します。フォントスムージングも同じ技法を使用しますが、アウトラインデータを拡大する前に、フォントのヒント情報を適用する点が異なります。ここではフォントのヒンティングについての詳しい説明は割愛しますが、簡単に言うと、フォントのアウトラインがピクセルグリッドに合わせて配置されるよう、フォントのアウトラインの縦および横のエッジをスナップするために「グリッドフィッティング」と呼ばれる方法がよく使われます。このような場合、フォントのほとんどの縦および横のステムは、拡大時に、基になるピクセルの 100% をカバーし、ダウンサンプリングされた時は、テキスト前景色（通常は黒）を返します。フォントの斜めの部分や丸みのある部分は、ピクセルを完全にはカバーしないため、一部は、基になるピクセルのカバレッジを反映した灰色の網掛けを返します。テキストに「ジグザグ」(より正確にはエイリアシング) が見られる場合、これは一般にグリフの丸い部分か対角線の部分で生じますが、ちょうどこの方法で灰色のカバレッジが返された領域です。この方法のアンチエイリアシングは、フォントにおけるステムのコントラストがより高く、一部の空間的精度のコストもごくわずかであるため便利です。

第 2 の差別化する要素は、フォントスムージングを有効または無効オフにする正確なサイズを決定するのは、フォントであるということです。このレベルの情報を提供するほとんどのフォントは、9 PPEM (pixels per em) より下のグレースケールアンチエイリアシングを有効にします。これは 96 PPI の画面では 7 ポイントに相当します。9 PPEM を超えると、フォントの主要ステムの幅が 2 つのピクセル程度、つまり約 13 ～ 20 ポイント程度でなければ、書体に応じてアンチエイリアシングは無効になります。主要ステムの幅が 2 ピクセルになると、サイズが大きくなってもアンチエイリアシングは有効なままになります。2 ピクセル幅のステムが一般的に基準とされるのは、ステムのコントラストが高い状態を維持するうえで、前景色のピクセルの「バックボーン」が 2 ピクセルあれば十分だからです。フォントスムージングに対する具体的なサイズがフォントで指定されていない場合は、システムの既定値が使用されます。標準書体とボールド書体はそれぞれ独立した既定値を持っています。したがって、フォントスムージングがデフォルトでも、ほとんどのフォントは、通常の読むサイズでテキストを表示する際、2 階調で表示します。

フォント レンダリングのデフォルト値

Windows XP に ClearType が追加されたことで、現在利用可能なフォントレンダリングの種類は 3 つ (2 階調、フォントスムージング、ClearType) となりました。Windows XP が開発されている間に、CRT モニターを備えたデスクトップ型から、ラップトップおよび LCD ディスプレイを備えたデスクトップへの明らかな移行が進んでいました。この移行はまだまだ完了しそうになかったので、私たちは Windows XP のフォントレンダリングのデフォルトは Windows 2000 と同様にグレースケールフォントスムージングにするべきだと感じました。システムとして Windows XP を提供する OEM は、このデフォルト値を変更できました。また、実際、Windows XP SP 2 が出荷される時期までには、OEM の多くが ClearType をデフォルトに設定していました。OEM は PC を構成する作業の一部として、これらの設定を常に変更できたことは注目に値します。

Windows Vista では、システムのデフォルトのフォントレンダリングは ClearType に変更されました。デフォルトのフォントレンダリングが何を意味しているかを明確に理解することが重要です。Windows では、デフォルトのフォントレンダリングとは、アプリケーションでレンダリングの種類が明示的に指定されていない時に使用されるレンダリングのことです。このデフォルト値が、すべてのアプリケーションが使用しなければならない値を意味するものと誤解しているユーザーもいました。この考え方は、Windows 95 のフォントスムージングが導入された時、テキスト API が機能した方法と矛盾しています。GDI では、現在のフォントを選択するための API は、レンダリングの種類を明示的に入力データとして持っています。どの種類のレンダリングを使用すると最適かをアプリケーションが一番よくわかっている状況があります。たとえば、小さなテキストが含まれている印刷プレビューページを表示する場合、レンダリング方法としては、従来のフォントスムージングが最良の選択肢となります。同様に、アプリケーションの目的が画面を読むことである場合は、そのアプリケーションのレンダリングとしては ClearType の使用が最も良いと思われます。状況によっては、リモートターミナルサービスのように、アプリケーションでリモートクライアントに送信する必要があるテキスト情報の帯域幅を減らすために、2 階調のレンダリングの使用を選択することもできます。

アプリケーションがシステムのデフォルト以外のレンダリングを使用するために、別の方法を使用するケースは多数あります。異なるフォント、カラー、サイズあるいは他のテキスト属性を使用するアプリケーションなどです。最も一般的な例は、ドキュメントのレイアウトおよびフローを複製可能にするようなアプリケーションです。テキストのレンダリング方法を指定できるようにすることで、アプリケーションはテキストが異なる PC で表示される方法を確実に指定することができます。別の一般的な例は、先にも述べた印刷プレビューです。特に小さなテキストサイズの場合に、より高い解像度の出力を適切にレンダリングして表示する能力が、非常に向上しています。私たちは、"表示" プロパティで表示される内容が、場合によってはアプリケーションで "覆す" ように選択できるものであることが、直観に反していると認識しています。私たちはデフォルトの状態での設定を考慮してレンダリングを設計しましたが、Windows 自体を含むアプリケーションでは明示的なレンダリング技法を必要とする要素がある場合もあります。

各アプリケーションはどのレンダリングを使用するかについて、フォント単位で選択できますが、大多数のアプリケーションはデフォルトのレンダリングを選択します。したがって、Windows Vista のデフォルト値を変更するという決断には非常にためらわれました。以前のブログの投稿で示したように、Windows XP および Windows Vista の実世界の遠隔測定によると、ハードウェアディスプレイの傾向は、CRT から LCD ベースのディスプレイへの急速な移行を強く示していました。まだ CRT が使用されている時期でも、Windows XP ユーザーからのフィードバックは CRT での ClearType レンダリングの品質に対して肯定的でした。私たちが Windows Vista のデフォルト値として ClearType を有効にすることを決定した後、この決定に対するフィードバックは、肯定的なものがほとんどでした。

デフォルトのレンダリングが ClearType に設定されているとしても、デフォルト値を変更できるシナリオがいくつかあります。OEM がハードウェアで Windows を提供している場合、OEM でデフォルト値を変更できます。状況によっては、ハードウェアがレンダリングテクノロジの最小要件を満たしていない場合があります。これは Windows 95 のフォントスムージングではより一般的でした。フォントスムージングと ClearType の両方の場合は、最低 16 bpp のディスプレイ解像度が必要です (GDI のオフスクリーンのビットマップにレンダリングする際、ClearType テキストをキャプチャしたい場合は、デフォルトの色深度が 1 bpp でないことが重要です)。場合によっては、システムパフォーマンスを最適化するために、フォントスムージング (ClearType とグレースケールの両方) を無効にできます。同様に、別のコンピューターあるいはセッションへの接続にリモートデスクトップを使用する場合は、通常、ClearType をデフォルトで無効にします。

Winodws 7 でデフォルトのレンダリングを変更する

Windows 7 では Windows Vista と同じデフォルト値が維持されます。ユーザーが Windows 7 のフォントレンダリングのデフォルト値を変更するには、いくつかの方法があります。デフォルトのレンダリングを 2 階調にしたい場合、この選択のユーザーインターフェイスは、コントロールパネルのパフォーマンスセクションにあります。コントロールパネルのルートから、[システムとセキュリティ] -> [システム] -> [システムの詳細設定] -> [パフォーマンス] セクションの [設定] ボタンの順に選択することでアクセスできます。もっと簡単な方法としては、スタートメニューの [検索] で「視覚」と入力して、「Windows のデザインとパフォーマンスの調整」を選択します。カスタムオプションの下で変更する設定は、次の図に示すように、[スクリーンフォントの縁を滑らかにする] です。

フォントスムージングをまったく使用しないことをデフォルトとする設定は、一般的ではないと考えられるため、他の設定よりも若干見つけにくくなっています。デフォルトのフォントレンダリングの選択内容を、先に説明した Windows グレースケーリングアンチエイリアシング技法に変更したい場合、Windows 7 では ClearType チューナーによって行います。

ClearType チューナー

ClearType テキストの品質は、ユーザーおよびモニターに対して最適化することができます。ClearType チューナーは Windows 7 の新しいコントロールパネルコンポーネントです。モニターの特性や読者の目には違いがあるので、そのモニター上でテキストを見る読者のみが最適化できるフォントレンダリングオプションがあります。ClearType チューナーは、ClearType アルゴリズムをきめ細かく調整するために視力検査の形式で表された、ClearType のさまざまなサンプルを使用します。各ウィザードページでは、モニターガンマ (電圧と明るさ間の関係)、色の影響に対する感度、文字の厚みの好みなどのパラメーターを調整します。

ClearType とグレースケールを切り替えるには、ClearTypeチューナーの最初のページの [ClearTypeを有効にする] で切り替えることができます。

いずれにしても、アプリケーションが ClearType レンダリングを明示的に有効にしている場合、一部のグラフィックスプラットフォームには、グレーレンダリングおよび ClearType の両方についてより細かい調整機能がある場合、ClearType チューナーウィザードは最後まで実行されます。

フォント デザインとフォント レンダリング

ClearType のような高解像度フォントレンダリング技法の登場は、画面を読むためのフォントのデザインに大きな影響を与えてきました。印刷機の時代から、新しい技術と印刷スタイルが開発されると、これらのテクノロジを活用するために書体がデザインし直されました。たとえば、現在でも使用されている多くの書体では、グリフの主要な特徴がインクでつぶれてしまわないようにするために、デザインに "インクトラップ" を取り入れています。これは、テクノロジを最大限活用するため、フォントにおいて特定のデザインの選択を行う 1 つの例です。従来の書体デザインでは、フォントという言葉は、所定のサイズでの書体を指します。したがって、10 ポイントの Times New Roman と 24 ポイントの Times New Roman は異なるフォントとなります。金属製のタイポグラフィの時代、それぞれのサイズは使用されるメディアに合わせてパンチカッターを使ってデザインされ、所定のサイズでのステムのコントラスト、x-height、文字間隔を変更しました。20 世紀半ばに写真植字が登場すると、活字のマスターとしての 1 つのサイズが使用され、それを光学によって任意の表示サイズに拡大縮小していたため、この点に関しては後退したことになります。

Microsoft Windows ではデジタルアウトラインフォントに対してより伝統的なアプローチを取ってきました。私たちは、フォントヒンティングおよび新しい書体デザインの組み合わせによって、意図されたメディアの各サイズを最適化しようと考えています。Microsoft の Windows 3.1 で初めてリリースされた TrueType では、伝統的な書体である Times New Roman、Arial、および Courier New が基本フォントとして使用されました。これらのフォントの作成では、1 つのマスターサイズがアウトラインデータとして選択されました。通常は、10 ～ 12 ポイントで、写真植字で使用された技法のように、アウトラインを所定のディスプレイ解像度の必要なサイズに拡大縮小しました。ただし、従来の方法にならって、各サイズの検査を慎重に行い、フォントヒンティングによって基本デザインを変更しました。これには、ステムコントラスト、x-height、グリフ間隔のような重要な特徴への変更などがありました。先にも言及したように、96 PPI の画面上の完全なピクセルといった低解像度の媒体用に調整するためのフォントのヒンティングは、非常に時間のかかる作業でした。Microsoft Windows におけるこの処理を助けるため、私たちは 96 PPI の 2 階調レンダリングの世界に最適化された新しいアウトライン書体のデザインの委託をしたり社内で独自にデザインしました。これらのカスタムフォントには、Tahoma、Verdana、Georgia、Trebuchet MS、さらには Comic Sans MS などがあります。個々のサイズを調整するためには、これらのフォントのヒンティングが必要となりますが、媒体を念頭に置いて書体がデザインされているため、より簡単な処理となり、それほど時間もかかりませんでした。

ディスプレイ媒体に合わせて調整された書体でも、画面上の 96 PPI ピクセルは、書体で表示したい多くの機能よりさらに大きくなります。そして、このようなところで ClearType が役立ちます。したがって、ClearType により、新しい媒体に最適化された新しい一連のフォントを依頼することは理にかなっています。Windows 用の既存のフォントは、このテクノロジで現在も十分に機能します。しかし、このプロジェクトは、ClearType を使用して画面を読むために最適なデザインを見つけようという試みでした。その結果、Windows Vista 用にチューニングされた新しいフォントセットが誕生しました。ClearType コレクションフォントである Calibri、Cambria、Consolas、Corbel、Candara、Constantia、新しいユーザーインターフェイスフォントの Segoe UI、および日本語フォント Meiryo は、この媒体用に設計されました。ClearType のデフォルトの設定と共に、これらのフォントプロジェクトのエンジニアリング作業の一部として、ヒンティングのプロセスでは ClearType 用のみ詳細なサイズ固有のヒントづけを行い、2 階調レンダリングではしないことに決めました。これにより、大部分のユーザーのために、より細かいレベルおよび高い品質を目指した作業に集中することができました。

Windows 7 の ClearType フォント

自分たちに対して質問すべきことは、Windows 7 で 2 階調またはハイブリッドのフォントスムージングをデフォルト値として選択すると、どのような結果になるのか? という点です。

前述のように、すべてのアプリケーションがデフォルトでレンダリングするように選択しているわけではありません。Microsoft Office と Internet Explorer は、一部のケースで ClearType レンダリングの使用がデフォルトとなります。2 階調レンダリングではなく ClearType 用にチューニングされたフォントを使用する一部のアプリケーションは、フォントデザインの利点を維持するために ClearType レンダリングを選択する場合があります。一部のアプリケーションは、サブピクセルポジショニングあるいは "自然幅 ClearType" のような高精度のグリフ幅が必要で、この場合に 2階調レンダリングまたはグレースケールレンダリングに変更されると、流れに逆らうことになります。Adobe Reader のような他のアプリケーションは Windows グラフィックスプラットフォームに依存しない独自の組み込みテキストレンダリングエンジンを備えています。同様に、Windows 上の Java のようなプラットフォームも独自のレンダリング技法を使用しています。

場合によっては、Windows 7 エクスプローラーで、Segoe UI が最適なデザインを維持するように、ClearType レンダリングがそのまま使用されます。Segoe UI から他のフォントにシステムフォントを変更することには問題があり、ダイアログボックスエントリの流れが逆になったり、テキストが折り返されて見えなかったり、ボタンのラベルが付いていないなどの問題につながります。ほとんどの人が Windows で使用されるフォントへのグローバルな変更を評価すると思いますが、たとえば解像度、DPI、言語などの領域にまたがって確実に維持するためには、現時点において、システムフォント設定に総合的な柔軟性を持たせることはできないということを意味します。

ClearType をオフにするという課題がある中、ClearType を利用できないシナリオに対応するための、フォントでの緩和措置があります。ClearType フォントの Calibri は、Microsoft Office のデフォルトのフォントであるため、フォントスムージンググレースケールが選択されたときに、フォントレンダリングの品質を向上させることを試みるため、変わった方法が取られました。この場合、ぼかしを除去するために小さいサイズのテキストでフォントスムージングを無効化するという正常な状況に反して、これらの小さいサイズのテキストで、文字の形状を改善するために、フォントはグレースケールを有効にしました。さらに、いくらかのキーサイズでは、Calibri フォントはアウトラインファイルにいくつかのビットマップフォントを埋め込みました。これらのビットマップは 2 階調レンダリングが要求された場合に役立ちます。これらのビットマップは、Calibri がリモート端末で使用されていて、リモート端末のデフォルトがパフォーマンス上の理由から ClearType に設定されていないという状況に対処することが目的です。

ClearType のパフォーマンス調査

先に述べたように、ClearType の背景にある目的の 1 つは、コンピューター画面上でテキストを読むパフォーマンスを向上させることです。私たちは、この作業の評価に関する複数の研究をサポートしました。研究は大学で行われ、専門誌で発表されています。ほかにもフォントに関係する Microsoft ブログがあり、そこでは読むパフォーマンスに関する研究内容が説明されています。それらのブログエントリに詳細および背景情報が説明されているため、ここでは、パフォーマンスの特徴のみいくつか説明することにします。

· 測定の結果、2 階調レンダリングに対して、ClearType を使用した場合、単語認識の正確さが 17% 向上しました。

· 分かったことは、2 階調レンダリングに対して、ClearType を使用した場合、読み取り速度が 5% 向上し、理解力が 2% 向上すること (これは注目に値します) です。5% の読み取り速度の向上は小さく思えるかもしれませんが、ユーザーが読み取りに費やす時間の長さを考えれば、累積した効果は大きなものになります。

· 分かったことは、読み取り速度の 5% の向上は広範囲におよぶテキストで継続されることです。また、ドキュメントスキャンのような非伝統的な読み取り作業では、2 階調レンダリングに対し、ClearType では約 8% も高速になることを発見しました。

· 分かったことは、部分的に最適化されたテキストを読むことは、目を細めることが増え、瞬きの回数が減るため、眼精疲労の原因になることです (当たり前に思えるかもしれませんが、この研究を行う前は、眼精疲労の生理学的なメカニズムはわかっていませんでした)。

レンダリングの好みに関する ClearType の調査

私たちが疑問に思った別の問題は、なぜ一部のユーザーが ClearType よりも 2 階調レンダリングを好むのか? という点です。ハードウェアに関する問題なのか、何らかの影響を持つ視覚のしくみについて、私たちも理解していない特性が存在するのか。これは長い間、私たちの好奇心を刺激した問題です。これをさらに調査しようとする初の試みとして、Microsoft の近くのコミュニティーセンターにおいて、非公式で小規模な好みの研究がなされました。2 台の同一のノート PC を、1 つは ClearType、もう 1 つは 2 階調レンダリングの設定で用意し、並べて配置して、参加者にどちらが好きかを尋ねました。これを 3 つの異なるサンプルに対して行いました。結果は次のとおりです。

	ClearTypeの方がよい	2 階調の方がよい	どちらでもよい
サンプル 1	33	1	1
サンプル 2	33	2	0
サンプル 3	33	2	0
平均 %	94%	5%	1%

備考:

参加者は 35 名。
2 階調レンダリングに対する感想:
ぼやけている。ジグザグ。粗い。これがプリンターだったら、新しいカートリッジが必要だったと思う。特に数字が消え入りそう。読むときは目を細めないといけなかった。眼鏡か、私のせいでしょうか? 集中することができない。気が散る。読もうと努力しなければならない。繋ぎ目がある。
ClearType に対する感想:
はっきりしていて、太く見える (複数回答)。濃く、はっきり見える (4 人)。コンピューターの画面が優れているように見える (ユーザーは、2000 ドルのノート PC に対して、画面が良くなるのであれば、さらに 500 ドル払ってもいいと提案しました)。青っぽくて、濃くて、読みやすい (3 人)。きれいで、切れがあって、こちらの方が好き、良く見えて、気に入っている。これは非常に明白に見える。

ほかに 2 つのテストを実施しましたが、2 階調レンダリングよりも ClearType を好んだのは、一方の調査では、30 人の参加者のうちの 28 人、もう一方の調査では、55 人の参加者のうちの 52 人でした。これらの 3 つのテストを総合すると、120 人中 113 人の参加者が 2 階調レンダリングよりも ClearType レンダリングを好むという結果になりました。このように、どちらか選ばなくてはならないテストでは、ClearType が良いと言ったからといって、その人が 2 階調レンダリングを嫌いなわけではない点に注意する必要があります。単に、どちらかといえば ClearType が良いということです。

2 階調レンダリングを好む人々についての詳しい検査は私たちにとっての最大の関心事であり、引き続き、大学の研究者と共にこのトピックについて調査を進める予定です。将来このトピックに関する論文が発表されことを期待しています。

今後の調査

この先、私たちの調査のほとんどは、最も高い品質のテキストレンダリングを誰でも利用できるようにする方法を見つけることにあります。どの視覚体系にもそれぞれ独自の特性があり、ClearType チューナーで表示特性のアルゴリズムをチューニングできるのと同じように、視覚体系の特性についてもチューニングできれば良いのではないかと思います。たとえば、米国では、男性人口の 7% は色覚障害を持っています。私たちは、ClearType アルゴリズムを向上させることで、障害を持っていない読者よりも、色覚障害を持つ読者にとってテキストがより見やすくなるようにできると信じています。高色感度の人や視力の低い人向けのテキストレンダリングを向上させる方法の研究も同様に重要です。

最後に

画面で読むことを最適な状態にすることは、私たちにとってワクワクするようなチャンスです。それは、さまざまな表示テクノロジと人間の視覚体系での取り組みというエンジニアリング上の課題と、美しい一連のグリフを作成するという芸術的な課題の融合であり、活字の細かいニュアンスすべてが重要となります。これを行う際に、私たち人間にとって最適な経験を実現するうえで、読むことに関する科学をどう利用するべきかに留意する必要があります。レンダリングテクノロジにはさまざまなユーザーにとっての利点と欠点があります。使用するアプリケーションによっては、トレードオフも伴います。これらの問題点の多くはユーザーが簡単に識別できるものではありません。私たちの役目は、優れたプラットフォームと、ユーザーがどのようにテクノロジを使用するか決めたりコントロールしたりするのに使用できるツールを開発者に提供するため、一生懸命努力することです。私たちの目標は、そのまま使ったときに適切に機能させることです。私たちは、通常、これを達成していると思っていますが、この領域は複雑で、さまざまなフィードバックがあるということも認識しています。

これらの問題に取り組んでいる Microsoft のチームは、1990年以来、フォントおよびフォントレンダリングソリューションを開発し、読むことの科学に関する理解を深めるために努力してきました。チームはエンジニア、設計者/アーティスト、および心理学者から構成され、Microsoft 中のその他さまざまな専門家と共に作業して、手強くて極めて重要な作業に取り組んでいます。あなたは、コンピューターでの作業の 80% 以上を、画面を読むことに費やしています。したがって、できるだけ快適なエクスペリエンスであるべきです。この IEEE Spectrum の記事は、テキストのテクノロジー、アート、および科学に関して、私たちが扱っている問題のいくつかを説明しています。

--Greg

Windows 7 グラフィックスパフォーマンスのエンジニアリング

e7blog — Sat, 23 May 2009 02:29:39 GMT

Windows 7 グラフィックス パフォーマンスのエンジニアリング

最高の CAD やゲーム グラフィックスなどデスクトップ グラフィックスのパフォーマンスは、Windows 開発の中でかなり多くのテストと調査が実施される分野の1つです。Windows をサポートする幅広いハードウェアとさまざまな利用シナリオは、基本的なフレーム レートからマルチ モニターでの最高のフレーム レートまで、さまざまな目標を持つエコシステムに役立ちます。Windows 7 の設計では、グラフィックスの最先端の要素を向上させる努力を続けると同時に、「実世界」のグラフィックスのパフォーマンスを向上させることを目指しました。当社のパートナーがドライバーを介してプラットフォームとなるハードウェアとソフトウェアの組み合わせを向上させるようとしています (注: Windows Vista ドライバーは、Windows Vista で機能したように機能し続けますが、Windows 7 用にドライバーを更新することにパートナーとともに取り組んでいます。これらのドライバーは、ユーザーの多くが Windows Update 経由でダウンロードしてテストしてきました)。この投稿では、広範な設計とパフォーマンスを測定するさまざまな方法について見ていきます。そして最終的に、異なるハードウェア上でさまざまなシナリオにより Windows 7 を比較テストしているみなさんに検討の余地を残しながら、Windows 7 の設計で実施した内容について報告します。この投稿は、デスクトップ グラフィックス機能チームのプログラム マネージャー、Ameet Chitreによって書かれました。--Steven

新しい PCの購入を考えるとき、「より高速なグラフィックス」や「卓越したパフォーマンス」は常に重要なアピールポイントとなります。写真を編集し、電子メールを実行し、高解像度ビデオを見て、最新の 3D ゲームをプレイする、これらすべてのタスクをシームレスに簡単で頻繁に行き来できる、そんなより高速なシステムをユーザーは期待しています。そのようなユーザーの多くは、グラフィクスベンチマークを実行するマニア的なコミュニティブログやさまざまなレビューサイトを参照し、新しいハードウェアまたはソフトウェアのグラフィクスの実行速度を評価して結果を報告しています。従来、グラフィクスパフォーマンスは、3Dゲームを通して測定および分析されましたが、Windows の UI を使い、ウィンドウを移動または最大化する、Word または IE などでスクロールする場合など「デスクトップシナリオ」と呼んでいるものにも影響を与えます。これらのデスクトップシナリオのパフォーマンス要件は、3D ゲームとはまったく異なります。実際、これが、Windows Vista エクスペリエンスインデックス (Windows Experience Index、WinEI) において、2 つのシナリオを別々に評価する理由です (以下の画像で強調表示している部分)。

図 1. WEI のサンプル (グラフィックス機能を強調表示)

グラフィックスパフォーマンスは、通常、多くのベンチマークによって評価されます。これらのベンチマークは 2 つの大きなカテゴリに分類できます。

シナリオ ベンチマーク: 特定のシナリオのパフォーマンス、たとえば、フライトシミュレーターである領域を飛行する際のフレームレートを報告します。一般のゲームの多くには、そのゲームの典型的なシーンでグラフィックスが実行する速度を実証するベンチマークモードが組み込まれています。
統合ベンチマーク: 可能な限り高速で多数の線を描く能力など、グラフィックスの特定の側面のパフォーマンスを強調表示します。

しかし、測定のベンチマークが存在しなくても、高速化のために重要なタスクは多数あります。この場合、Windows 内の計測機能を使用して、タイミング情報を取得し、パフォーマンスを分析します。

このブログでは、グラフィックスパフォーマンスのさまざまな側面、ゲームおよびデスクトップグラフィックスのパフォーマンスの両方について説明します。ユーザーのフィードバックに対応し、最新のハードウェアを活用して、グラフィックスパフォーマンスを向上するために Windows 7 で行った変更について説明します。

デスクトップの応答性

多くのユーザーが、アプリケーションまたは Windows そのものが一時的に応答を停止することを経験しています。これは、PC のグラフィックスパフォーマンスによって大きく影響を受けるパフォーマンスの問題の一種です。この問題はデスクトップの応答の問題として分類されています。応答しない時間をなくすことは、システムでパフォーマンスを向上させる重要な方法の 1 つです。しかし、これを測定することは困難です。

応答に影響を与える問題の多くは、簡単に再現できず、また、非常にさまざまな問題があるため、デスクトップの応答性を測定することは、難しい問題です。これらの問題は現実の要素の組み合わせに依存するため、いずれの種類のベンチマークでもほとんど問題の本質を捉えることはできません。Windows 7 では、重要な OS イベントとそれが発生した時間を記録する機能を持つテスト版 Windows 7 のメカニズムを使用して、パフォーマンスの誤動作を調べることに相当の時間を費やしました。実世界でのシナリオに基づいたテスト中に応答の問題が発生した場合、テスターは記録キーを押して、発生した問題の簡単な説明を入力できます。「パフォーマンストレース」という診断情報を含むイベント履歴がファイルに書き出され、サーバーにアップロードされます。サーバーでは、パフォーマンス分析者のチームがデータを解析して応答の問題の原因を解明します。このプロセスは、現在、問題の多くを迅速に追跡し、問題の根本原因となる範囲において成果を上げています。

この方法を使用して、ベータテスターのみなさんが経験した 100 ミリ秒から数秒までのデスクトップのフリーズに関する大量の応答トレースを分析しました。問題の種類は、ウイルス対策プログラムがメーカーの Web サイト上で自身の更新中にすべてのアプリケーションによるディスクアクセスをブロックしていたものから、アプリケーションが UI スレッドからネットワークアクセスを実行していたものにまで及びました。これらのトレースのかなりの部分で、ある GDI アプリケーションが別の GDI アプリケーションを待機し、そのために過剰なページング動作が発生して速度が大幅に低下していることを発見しました。これが、デスクトップ応答の問題において単独で最も頻繁に発生する原因であり、このデータなしには特定できませんでした。これらの調査に基づいて、次の 2 つの主要な分野においてアーキテクチャの改善を行いました。

GDI 自動実行: 複数のアプリケーションが実行されている場合の応答を向上させます。これには、GDI (Graphics Device Interface) 同期オブジェクトまたは「ロック」のコードの再設計が必要でした。
Windows の全体的なメモリの占有領域の削減: デスクトップのレンダリングを担うコンポーネントであるデスクトップウィンドウマネージャー (DWM) に構成されるメモリオーバーヘッドを削減します。これにより、ページング動作を削減でき、特に共有グラフィックスメモリを使用しているような、メモリの少ない PC にとって特に重要となります。

これらについて、さらに詳しく説明します。

GDI 同時実行

デスクトップ応答がどのようなものか調査した多くのパフォーマンストレースによって、GDIの同期メカニズムを設計するためのポイントが明確になってきました。Windows Vista における GDI の設計では、単一のアプリケーションだけがシステム全体にわたる排他的グローバルロックを保持できるため、パフォーマンスの課題が発生します。後から考えると、これは明白ですが、当初、この決定がなされたとき、システムのさまざまな部分でのパフォーマンス特性により、この楽観的な実装は完全に合理的であるとされていました。

図 2. 既存アーキテクチャでの GDI 同時実行

同時に動作する GDI アプリケーションでは、画面でレンダリングするために、このグローバルロックが競合します。グローバルロックにアクセスするアプリケーションにより、それがグローバルロックを解放するまで、他のアプリケーションはレンダリングすることができません。ディスクから RAM までメモリを移動することに比較的長い時間がかかるので、ロックを保持しているアプリケーションでディスクから大量のメモリでページングする必要がある場合には、多くの場合、状況は悪化します。上の図では、2 つの GDI アプリケーションが同時に実行されており、グローバルロックが競合します。App X がロックの維持を取得した場合、画面にレンダリングできますが、App Y はレンダリングできず、App X がレンダリングを終了するまで待機します。

図 3. Windows 7 アーキテクチャ でのGDI 同時実行

したがって、問題に対する解決策は、ロック競合を減らし、また、確実に複数のアプリケーションが同時にレンダリングできる内部同期メカニズムを再設計することにより、同時実行を向上させることでした。排他的グローバルロックによる競合は、排他的ではなく並列処理を促進する複数の詳細に設定されたロックの実装により避けられます。詳細に設定されたロックが増加すると、単一のアプリケーションだけが一度にレンダリングしているシナリオに対して小さなオーバーヘッドが追加されます。

最も広く使用されている API スタックの内部同期メカニズムの変更により、デッドロックやレンダリング破損などのタイミングの問題を潜在的に生じさせることがあるので、GDI アプリケーションの互換性に特別な注意を払う必要がありました。

また、この作業は、マルチコア CPU 上で同時実行の GDI アプリケーションのレンダリングパフォーマンスを向上させることになりました。現在では複数のアプリケーションで同時にレンダリングできるようになったため、マルチコア Windows PC では、この変更の利点を活用できます。

GDI 同時実行作業がベータ版の元となる Windows 7 ビルドに実装された後、GDI によって 1 つのアプリケーションが別のアプリケーションをブロックすることに起因するデスクトップ応答の問題について、テスターからの報告件数が大幅に減少しました。さらに新しい実装のスケーラビリティを検証するために、2D の GDIプリミティブを描くテストを作成し、複数のアプリケーションを同時に起動することによってレンダリングスループットを測定しました。スループットは、各アプリケーションウィンドウのフレームレート (FPS) を同時に追加することにより測定されます。下記は、クワッドコア CPU システム上でのこれらの結果のサンプルです。

図 4. GDI 同時実行とスケーラビリティ.

Windows 7 の GDI 同時実行なしでは、これらのアプリケーションのレンダリングスループットは、事実上、単一 CPU コアのパフォーマンスに制限されます。別のアプリケーションが待機している間に、1 つのアプリケーションだけが排他的なグローバルロックを取得できるので、このシナリオでは複数の CPU コアを持っていてもそのメリットを活かせません。ここでは、Windows 7 のGDIアプリケーションは、現在ではお互いにほとんど依存しないことを示しています。この利点では、新しいディスプレイドライバーを必要としません。Vista (WDDM 1.0) およびより新しいディスプレイドライバーのいずれでも機能します。

デスクトップ グラフィックス - メモリの占有領域の削減

システムの応答性に影響を与える別の分野は、メモリ使用量です。簡単に言えば、システムメモリ (RAM) 使用量が増加すると、システム応答を直接低下させるページング動作の増加につながります。したがって、最適の応答では、すべてのアプリケーション、プロセス、および OS コンポーネントがシステムメモリを可能な限り使用しないことが必要です。

Windows Vista では、複数のウィンドウの実行に必要なメモリ量は、システム上で開かれたウィンドウ数に比例します。これは、ウィンドウをさらに増やした場合、または、モニターでより高い解像度を使用した場合、より大きなメモリ圧力につながります。複数のモニターを使用する場合、さらに悪化します。システムの応答性を向上させるさまざまな手段を調査していく中で、DWM によるシステムメモリの使用量を大幅に減らせる可能性を発見しました。Windows Vista では、すべての GDI アプリケーションウィンドウは、まったく同じコンテンツのメモリ割り当てを 2 つ、ビデオメモリ内とシステムメモリ内に持っています。DWM は、グラフィックスハードウェアによるデスクトップの構成を担当しています。したがって、グラフィックスハードウェアが簡単にアクセスできるよう、ビデオメモリ内に同じ割り当てのコピーを必要とします。システムメモリ内の重複コピーですが、GUIはオペレーティングシステム内で、グラフィックハードウェアによって支援または「高速化」されることなく、完全に CPU を利用してレンダリングされます。つまり、GDI アプリケーションをレンダリングするすべてのタスクは CPU が実行するため、CPU は容易にアクセスしてキャッシュできるメモリのコピーを必要とします。

図 5. 既存のメモリ割り当て

一方で、Windows 7 では、システムメモリのコピーを完全に削除し、1 つのアプリケーションウィンドウあたり 1 つのメモリ割り当てコピーを保存します。したがって、デスクトップ上に表示される GDI アプリケーションウィンドウでは、消費されるメモリは半分に削減されます。

図 6. Windows 7 でのメモリ割り当て

私たちは、グラフィックスハードウェアを活用して共通の GDI 操作を高速化することにより、システムメモリの削減を達成しました。WDDM ドライバーでは、GDI 操作を高速化して、ビデオメモリの CPU リードバックのパフォーマンスの影響を最小限に抑えます。これらの操作を実行しなければ、CPU 上で重大なパフォーマンス上のデメリットが発生するため、必要な処理でした。高速化する GDI 操作を決定するためには、さまざまな GDI アプリケーションの使用パターンを分析することが重要です。GDI アプリケーションの呼び出しパターン、および GDI 操作の頻度と性質についての詳細を理解するために、上位 100 個の GDI アプリケーションをプロファイルしました。

図 7. 100 個の GDI ベースのアプリケーションでの GDI 操作の呼び出しパターンおよび頻度

上記の小さなスナップショットで示すように、実世界のアプリケーション統計に基づいて、最もよく使用される GDI 操作を高速化するために、グラフィックスメーカーのパートナーと協力して、これらをサポートするドライバーを提供しました。「WDDM v1.1」というこの更新されたドライバーがインストールされた Windows 7 のシステムでは、このメモリ節約作業の恩恵を受けられます。なお、WDDM 1.0 ドライバーもWindows 7 上で完全にサポートされます。ベータ期間中に Windows Update でこの 1.1 ドライバーを提供していることに気が付かれたかもしれません。これらのドライバーも、ベータ版です。

図 8. WDDM 1.1 と WDDM 1.0 を使用した場合のデスクトップ ウィンドウ マネージャーのメモリ消費量の比較

上記のデータでは、デスクトップ上で複数のアプリケーションウィンドウを表示した場合、メモリの節約がますます必要となることを示しています。たくさんのシステムメモリを節約すると、ページング動作が削減されます。その結果、システムの応答性は同じワークロードに対して向上します。

デスクトップの応答性の向上のために、ある種のトレードオフが発生します。たとえば、特定の操作の「迅速化」が導入されたシステムメモリの重複コピーを排除することにより、CPU でデータをビデオメモリから読み込む必要があるため、パフォーマンスがわずかに低下しました。しかし実世界のアプリケーション統計の分析では、これらの操作がほとんど実行されなかったことがわかっています。ただし、これらの操作を発行する特定の GDI ミクロベンチマークでは、一部でパフォーマンス低下が見られます。これは、特定の GDI 操作に繰り返しストレスを与える既存のベンチマークを実行した場合、注意が必要な点です。なぜなら、実世界でのパフォーマンスを反映しているとは限らないからです。速度の低下がエンドユーザー機能に直接影響を与えないこと、また、メモリの節約が Windows 7 で全体的に応答を良くする結果に直接つながることがわかっています。全体的な向上点は、共有メモリグラフィックスを備えた、メモリ制約がある PC の場合に顕著となります。

ゲーム パフォーマンス

ゲームのことを語らずに、グラフィックス パフォーマンスの話を終わりにすることはできません。ゲームは今でも広く分析され議論されています。ベンチマークには、3DMark など一般的なものから、ゲームを実行している最中にユーザーによるインタラクションなしに実行できるようなゲームに組み込まれたものまで、さまざまな種類があります。この分野は、ゲーム業界によって、実際のゲームをかなり現実的に表すさまざまな業界ベンチマークを使用して、詳しく追跡記録されてきました。さまざまなベンチマークやテストが広く検討され、ゲームのプレイヤーはこれらの測定の微妙な点まですべて精通し、その結果をプレイヤーのハードウェア、ドライバー、およびゲームに対する期待値に応じた推奨事項として役立てています。

Windows 7 では、グラフィックスパートナーと密接に協力し、同じドライバーモデルおよび互換性を維持しつつ、Windows 7 の動作への特定の変更を行って WDDM ドライバーのゲームパフォーマンスを向上するための作業を行ってきました。パフォーマンスツールへの継続的な投資により、マイクロソフトおよびハードウェアパートナーは、さまざまなゲームパフォーマンスのボトルネックを追跡して分析し、それらのボトルネックを次のドライバーリリースで修正することが可能となりました。Windows Display Driver Model の基礎は Windows 7においても変更ありません。GPU スケジュールおよびメモリ管理に関する一部のポリシーは、特定のシナリオにおいてより適切なパフォーマンスを可能にするために変更されました。

これらのベンチマークは、特定のハードウェア、ファームウェア、ドライバー、システム全般に対して非常にセンシティブであるので、また、他の場合では、非常に広範に測定および検討されているので、これらの比較をサードパーティに行ってもらう予定です。Windows 7 の多くの分野がそうであるように、マイクロソフトの責任は、多くの側面にわたってより最適なパフォーマンスを設計することです。みなさんには、これらの取り組みを直接体験していただくのがよいと思います。Windows 7 を比較する際は、Windows Vista SP1 の使用をお勧めします。また、WDDM 1.0 と 1.1の相違点について、および 1.1 ドライバーがまだ開発中であることに留意してください。

最後に…

ご存知のように、Windows 7 の設計では、実世界のパフォーマンスに関するグラフィックス向けのアーキテクチャを向上させるために努力してきました。これは、どのようなハードウェアでも有益です。物理メモリが少ないシステムでも高速で効率的に Windows を実行でき、同時に、マルチコア PC では複数のグラフィックスアプリケーションをとても効率的にレンダリングできるようになります。

-Ameet

Windows 7 でのタイポグラフィーとテキスト・レンダリングの進歩

e7blog — Thu, 12 Mar 2009 10:36:46 GMT

PCで画像とビデオを観ることは非常に普及していますが、私たちの多数は大部分の時間をテキストを見て対話することに費やしています。私たちはテキスト表示品質向上のためのテクノロジーを追求していきます。この領域では引き続き、ディスプレイ、グラフィックスカード、そして開発者が利用できる API レベルで、向上したテクノロジーを活用することができます。Windows 7 では、GDI でのテキストとフォントのサポートを、互換性とアプリケーションのサポートの基礎として引き続き提供します。現代の DirectX グラフィックスインフラストラクチャの基礎に基づいて、Windows 7は Direct Write を使用して開発者が利用できるテキスト出力を拡張します。これは新しい API サブシステムで、Microsoft やソフトウェア開発者のアプリケーション、および Windows 自体でも、より長期にわたり広く採用されることでしょう。この投稿では、Clear Typeとフォントの向上点に (両方ともGDI ベースのテキスト API の向上点の部分として利用可能)関しても取り上げます。この取り組みは PDC (投稿の下記を参照のこと) で紹介されました。この投稿は Walachia Chaoweeraprasit (私たちのグラフィックスフィーチャーチームの開発リーダー) によるものです。 --Steven

Windows 7 の大きな目標の 1 つは、より優れたグラフィックス、より高い忠実度を備えたグラフィックスを用意することでもあります。この目標に向かい、私のチームは、Windows で最も基本的なグラフィックの要素のうちの1つ、つまりテキストを向上させる方法を研究しています。テキストは常に目の前にありますが、気にならないほど自然な存在であって欲しいと思います。

よいテキストの必要性

ユーザーは PC の使用において約 80% を読み書きに費やします。コンピューターは実質的にユーザーにテキストで対応するため、これは驚くべきことではありません。コンピューターが人間の脳へ直接考えを伝えられるようなテクノロジーを持つまでは、テキストが引き続きコンピューター画面から情報を受け取る方法です。

研究によると、よいテキストはより高い生産性につながります。私たちは人間として、実質的に単語をキャプチャーし、それらの間を信じられないほど滑らかに、そして迅速に移行することが得意です。それが、読み取りのベースとなっています。私たちはその能力に非常に長けており、テキストがそのプロセス用に最適化されていれば、それらは信じられない速度で、しかも無意識に行うことができます。なぜ多くの人が本を短時間でさっと読むことができるか、またコンピューター画面をしばらく凝視した後すぐに疲労してしまう人がいることを、これによって説明できると思います。しかし、読み取りプロセスを妨げるようなあらゆる視覚的な関連要因が、実際に私たちの読み取り速度を遅くします。したがって、よいテキストとは可能なかぎり注意をそらす要因が少なく、ユーザーの読み取りプロセスをサポートするために調整されたテキストです。

各文字、単語、行および段落を囲む白地の均等さは、読み取りのペースを保つために非常に重要な役割をはたします。一方、黒い要素は、私たちの注意を集中させます。長すぎる行、詰まった単語、不均等な段落、およびこのような条件は、読んでいるメッセージからますますユーザーの注意をそらし、それを伝える単なるメディアにどんどん注意を向けさせます。テキストアートとは実質的に、テキスト自体は目の前から消え、その結果、それが伝える考えがあなたの頭の中で再生させることです。適切なテキストを準備する方法に関する研究は、タイポグラフィーとして知られています。また、タイポグラファーが言うように、よいタイポグラフィーは“見ることができない”のです。よくないものだけが見えます。プラットフォームとしての Windows の役割は、優れたテキストのプレゼンテーションの提供、およびソフトウェア開発者向けに、開発しているソフトウェアのコンテキストで可能な最良のプレゼンテーションを作成するための優れたツールを提供することです。

現在の技法の向上

ユーザーは習慣によって行動する傾向があり、しばしば時間とともに、これらの習慣は優先的な方法になります。その行動がありきたりであるほど、私たちはより容易にその習慣にとらわれてしまい、それを変えるのがより困難になります。スクリーンのテキストに関していうと、ユーザーは一日中同じ画面を見ています。それが一夜にして完全に変化すると、たとえそれがよい方向への変化であっても、即座に厄介なことになるかもしれません。そうなると、ユーザーがそれほど使い慣れたものを、私たちはどのように向上させられるでしょうか。私たちは確実に、そこにあるものをサポートし、また既存のメソッドをサポートしながらそれを向上させたいと思います。しかし、向上点を理解する前に、最初に現在の実装、およびこの数年にわたって存在している課題をより詳細に見ていきましょう。

現在の実装はデバイスピクセルに基づいたテキストレンダリング設計の製品です。特定のサイズのテキストのディメンションは、最終的にデバイス面の水平および垂直方向のピクセル定数へ変換されます。10ポイントのテキストは、通常の 600dpi のプリンターデバイス上でおよそ 80 のピクセルの高さに変換されます。一方、同じテキストが、96dpi モニター上では単に 13 のピクセルになります。この物理的な画面状況は、画面上のよいテキストのために必要な品質としては、ほとんど適切ではありません。

幸運にも、過去十年における Clear Type の出現は、主に品質における明瞭さの側面を向上させました。Clear Typeは、LCD ピクセル構造の分析に影響を与え、人間の視覚的なシステムを活用しました。個々のピクセルを構成する LCD の通常の 3 つのカラーのチャンネルにおいて、全体のディスプレイピクセルで近隣のサブピクセルにエネルギーを配分することにより、視覚的な幻覚を作成し、低い解像度のデバイス上でより高い解像度ラスター品質をもたらします。結果として、Clear Typeテキストは LCD ディスプレイ上の通常のテキストより大幅に鋭く見え、そのあとで非常にポピュラーになった表示テクノロジーに関する品質問題の大部分を軽減しました

Windows の最初の Clear Type の別の設計は、それがアプリケーション互換性を弱めることなく、テキストの明瞭さを向上させたということでした。すなわち、それはどちらの方向でも個々のグリフの実寸法を変えず、隣接した 2 つの間の距離を変えません。これにより、ユーザーはドキュメントやアプリケーションで選択されたオプションを「格納する」必要なく、自由に切り替えることができました。それは、完全にユーザーごとのレンダリングリファレンスです。Windows 7 では、さらにユーザー自身が PC エクスペリエンスをコントロールするというテーマにそって、ClearType をチューニングする場合により詳細な選択肢を提供することにより、ClearType Text Tuner を向上させました (今までどおりそれをオフにできます)。

しかし、世界の他の多くの場合と同様、コインには 2 つの面があります。下位互換性を保持していますが、技術を向上させたその独自の機能によって制限を受けます。個々のグリフの幅と高さおよび隣接した2つの間の名目距離は、所定のサイズでのスクリーンピクセルの丸められた数に修正されたままです。

私たちが Windows 7 でもたらしたグラフィックスの向上点の 1 つは、かつての物理ピクセルモデルから移行し、代わりに、いわゆる「デバイスインディペンデントピクセル」単位（または「DIP」）、浮動小数点データ型で 1 インチにつき 96 分の 1 である「仮想ピクセル」に関連して新たな設計を行ったことです。このモデルでは、グリフ (あるいはこれに関する他の幾何学的なプリミティブ) を、断片的なピクセルにサイズ変更でき、2 つのピクセル間のどんな場所にも位置することができます。新しい Clear Type 向上点は、グリフのサイズ変更および配置によって、画面のサブピクセルを最も理想的な状態に近づけるのを可能にしました。より自然に見える字形を作成し、画面上のテキストを印字品質により同じに見えるようにします。

下図で、従来あるいは現在の Clear Type (上) および Windows 7 の向上点 - Natural Clear Type (下) による同じ単語を並べて示しました。なお、Natural Clear Type は、レンダリング用の新しい API の呼び出しが必要です。単語内の文字の幅および文字間の広さ、さらにより一貫した幅および間隔が全単語の全体的な外観を向上させていることに注目してください。文字はすべて標準間隔で配置され、カーニング調整は適用されていません。高度な読み取りテクノロジーチームの研究者であるケビン・ラルソンによる優れた論文において、単語認識の科学的な側面が詳述されています。

自然なテキストの画面配置へ近づけるという機能は、さらに非常によい副産物をもたらします。それは、実際のディスプレイデバイスの解析度を考慮することなく、テキストを行の上に配置できるという事実です。それは、ユーザーが持っているディスプレイデバイス型にかかわらず、ある画面で見えるのと同じに、他のすべての画面でも同じに見えることを前提に、UI 設計者がアプリケーション UI を設計できることを意味します。この事実は、翻訳されたテキストが同じレイアウトで至るところに作成されるソフトウェアローカリゼーションにとって特に便利です。

この向上点は、さらに画面上での印刷ドキュメントのより現実的なビューを提供します。画面ドキュメントをそれに相当する印刷に近づけることができます。それはさらに、ドキュメントのズームの品質も向上させることができます。実際の印刷物を目に近づけたり遠ざけたりして見るようにできるキュメントのズームを想像してください。これにより、オンラインでの読み取りがよりよいエクスペリエンスになります。

フォントおよびフォント管理

“フォト”がフォトグラフィの要であるように、“フォント”はタイポグラフィの要です。Windowsでより多くのフォントが出荷されていますが、さらに多くのフォントが世界中で開発されています。Windows Vista は、Windows XP に比較すると、40 % 増のフォントを出荷しました。Windows 7 でも傾向は踏襲され、40% 多い新しいフォントを出荷すると予想されます。さらに、関連フォントの大きなライブラリとの協力を向上させるために、Windows 7 エクスプローラを使用するいくつか表示/分類機能を追加しました。

既定の共通コントロールのフォントダイアログおよび Windows 7 リボンのフォントチャンクも、どのフォントを現在のユーザープロファイルのユーザーに存在させるか、よりインテリジェントに選択できるように更新されます。現在の UI 言語、ユーザー・ロケールおよびキーボード入力ロケールの現在のセットなどの複数の設定に基づいて、フォント一覧は、異なる文化とロケールのユーザーには通常使用されない言語のフォントを非表示にします。たとえば、混乱を減らし、生産性のレベルをより上げるためにメモ帳、ワードパッドおよびペイントのような共通のシステムアプリケーションでは、すべての国際的なフォントは自動的に通常の英語ユーザーから隠されています。リボンあるいは共通コントロールのフォントダイアログを利用するサードパーティアプリケーションでも、同じ利点があります。ユーザーは、Windows 7 コントロールパネルのフォントアプレットで明示的にそれをマークすることにより、どのような希望のフォントもビューに選択できるオプションを保持します。

オペレーティングシステム	出荷された「インボックス」フォント
Windows XP SP2	133
Windows Vista	191
Windows 7	235 (現在のプラン）

この増加は、向上のいくつかの新しい機会をもたらします。私たちは長い間フォントをシステム全体のリソースとして扱ってきました。それはコンピューター上に「インストールされ」、オペレーティングシステムのコア部分によって管理される単一の水平な名前空間中で維持されます。不思議と思われる方もいると思いますが、「Arial Balch」は、実際には「Arial」あるいは「Arial Narrow」とは同じグループではありません。つまり、オペレーティングシステムに関係する限り、それらは異なる名前を備えた異なるフォントなのです。また、フォントはその名前によって一意に識別されるので、同じフォントの複数のバージョンを同時に持つことができません。

フォントはシステムリソースであるため、ドキュメント内で埋め込みフォントのようなフォントの非伝統的な使用、およびアプリケーションで排他的に使用されたフォントは、個人のインストールとして既知の機構によって行われます。それにより、フォント名がそれをプログラム的にはインストール前には一意ですが、他のフォントを非表示にすることによってそのように機能します。プライベートフォントは、内部オペレーティングシステムに関する限り、パブリックにインストールされたフォントと同じです。

Windows 7 の新しいフォント形式の重要な向上点は、パーティション分割によって、同じ使用をフォント分離した名前空間へ共有するのを可能にする「フォント集合」の概念です。システム集合は、現在存在するものに似ており、システムによって作成および管理されます。カスタム集合は、必要に応じて、完全にアプリケーションプログラムによって、作成および管理されます。これにより、ドキュメントに独自のローカルフォントのセットを持つことを可能にし、サードパーティアプリケーションあるいはプラグインを、プログラム内で排他的に使用される独自のフォントと共に出荷できるようにします。このパーティション分割は、不要なシステム全体のフォント更新を減らすだけでなく、更新がローカルに必要な場合にのみ起こるようにできます、さらに、異なる集合内の同じフォントの複数のバージョンへのアクセスを可能にします。

新しいフォント形式は、フォントが集合内に整理される方法を向上させ、ウェイト幅傾斜バリエーションの概念をサポートします。ウェイト幅傾斜バリエーションでは、同じ文体ルートを持っているが、ウェイト (太い、細い、黒など)、幅 (広い、狭いなど)、傾斜 (イタリック、斜体) において異なるフォンが、同じフォントファミリー内に一緒にグループ化されます。たとえば、「Arial Narrow」は、「Arial」ファミリの 1 つのバリエーション、つまり書体です。このグループ化モデルはCSS推奨事項によって提唱されています。

フォントアート

フォントは、アート(芸術) および芸術的な表現にもなります。したがって、フォントの作成を支援するテクノロジーは、芸術家が表現するためのツールとなります。過去 10 年の間に、OpenType と呼ばれる重要なテクノロジーが登場しました。これにより、活字デザインを実現できる新しい方法が可能になりました。OpenType を使用することで、デザイナーは、製作の段階でグリフをどのように組み合わせて、変形するのかを定義できるようになりました。その結果、デザイナーは、この機能を、アプリケーションプログラム可能なアクセス用の「フォント機能」と呼ばれる実行可能な単位として公開することができます。

OpenType は、マイクロソフトが 1994～95 年に開発した TrueType オープンテクノロジーから派生したものでした。TrueType オープンテクノロジーでは、TrueType フォーマットに、GSUB、GPOS、BASE、JSTF、および GDEF テーブルが追加されました。当時の主な用途は、Arabic フォントの作成を支援することでした。この作業には固有の複雑さがあったからです。マイクロソフトは 1996 年にこのテクノロジーを OpenType という名称に変えることにしました。そして、Adobe は同じ年に、このテクノロジーに、彼らの CFF グリフアウトラインフォーマットを追加しました。現在、OpenType は、さまざまな言語において、テキストの読みやすさを向上させる共に、新しく刺激的な活字デザインを表現するために使用されています。

しかし、長年存在し続け使用可能な状態にあったにもかかわらず、Windows 業界における OpenType の用途の大部分は、特殊なプログラムに限られたままでした。Windows ネイティブのグラフィックスシステムでは、OpenType をテキストに対するその本来の用途として、十分には活用していませんでした。この物足りなさが多くのデザイナー達をがっかりさせています。その理由は、Windows に、彼らが作成した機能をテストする標準的な方法がないからです。同様に、公開が制限されているため、本来のアプリケーション開発者の発見可能性が促進されません。この状況を改善し、この改善されたレンダリング技術に移行することは、(互換性がないものとして紹介されてしまう可能性のある) 混乱状態を最小限に抑えながら、利益を最大にするために実施させるため、いくつかの段階を経る必要があり、そのためいくつかのリリースにまたがっていくことになるでしょう。Windows 7 では、この目的に対して別の手段をとっています。この領域に深い関心を持つ大多数の人たちには、より迅速に移行したいという強い願望があるということを私たちは知っています。私たちは、移行のスピードと、互換性を維持したいという願望とのバランスをとるために、最善を尽くしています。

Windows 7 の新しいテキストシステムでは、利用可能な OpenType 機能を内部で使用するだけでなく、高レベルのプログラミングインターフェースにおけるフォントで利用可能な機能へのアクセスも可能なり、アプリケーション開発者が本来のシナリオで簡単に、フォント機能を発見して用いることができるようになりました。Windows 7 には、広く尊敬されているタイポグラファーの John Hudsonが開発した最新のOpenTypeフォント「Gabriola」も搭載されています。Gabriola では、文脈依存の字形を多用しており、状況に応じで異なるフォントを使用するために、前例のない程多くの数の文体のセットが用意されています。下の図は、このフォントで利用できるすべての文体のセットを列挙したものです。各々の文体のセットを識別する微妙な点とそれほど微妙でない様式に注意してください。

また、下の図は、Gabriola の文体のセット (「ss07」) の 8 番目の表現における文脈依存の字形が持つパワーを示しており、同じ単語をレンダリングする場合でも、行内の配置場所に応じて、さまざまな様式が生み出されています。

新しい API

テキストをレンダリングすることは、簡単なように見えても、実際は複雑です。おそらく、文書でテキストの書式設定を行う方法には何百もの方法があり、多くの場合、最終的に同じ結果を生み出す多数の道筋があります。HTML/CSS は複雑な規格であり、テキストを書式設定して活字化する方法の豊富さの良い例となっています。言語の要件、つまり言語を記述するルールは、書式設定のロジックの下にあります。Windows は、長い間 Unicode (グローバルなデータ交換のためのもう1つの複雑な規格) をサポートしてきました。Windows は、すべての単一リリースで、増大しつつある Unicode スクリプトをサポートしています。入力テキストからフォントの最終的なグリフへのマッピングには、複雑な変形が要求され、フォントデータの解析と言語記述パターンの分析が必要になります。一旦グリフが確定されれば、ラスタライズ、マージ、およびフィルタリングが行われ、最終的にディスプレイ装置に表示されます。

このステージング特性のために、テキストシステムからは、アプリケーションの種類ごとにそれぞれ異なるサポートが必要になります。伝説的な「Hello world」タイプのアプリケーションのような、代表的アプリケーションは、ユーザーに単にテキストを見せるだけの機能であれば満たすことができます。しかし、Microsoft Word や Adobe InDesign などの文書作成システムでは、このレベルのサポートでは、全く不十分です。より成熟した一部のアプリケーション・コードベースでは、さまざまなグラフィックシステムに対処できることも必要になります。このため、Windows エコシステム内の多種多様なアプリケーション全体で広く役に立つにようにすることは、特定のグラフィクスモデルに結びついたテキストシステムには、実際には非常に困難なこととなります。

テキスト処理は均一なものではなく、さまざまな種類のアプリケーションが、それぞれ異なるニーズを持ち、異なるレベルのサポートを必要としている、ということが、Windows 7 の計画の初期段階で明らかになりました。テキスト機能への、適切なレベルでのプログラミング・アクセスが、機能そのものと同じくらい重要となります。Windows 7 の新しいテキストシステムは、DirectWrite と呼ばれている自給自足のシステムにまとめられています。APIは、4 つの層 (フォントデータ用のインターフェース、レンダリングのサポート、言語処理および活字設定) で提供され、それぞれの層は別の層の上に構築され、低位の層は上位の層に対して要求を行わず、特定のグラフィックモデルに依存するものはありません。後者のポイントを例示するために、下の図では、Direct2D と呼ばれる Windows 7 の新機能でもある 2D グラフィックス環境から押し出され塗りつぶされた 3D ジオメトリとして最終的なレンダリングが行われる間、新しい活字設定インターフェースと言語プロセッサを使用する、サンプルアプリケーションを示しています。両方のシステムが、Windows 7 に基づく新しいグラフィックの基盤として、 PDC 2008 に導入されました。

DirectWriteは、3 つの重要な側面で、GDI や GDI+ などの既存のテクノロジーへの開発者の投資をサポートします。まず第一に、DirectWrite の前に述べた階層化設計により、テキストの配置とレンダリングという 2 つの基本的なプロセスの間を明確に分けることができます。これにより、複数のアプリケーションが DirectWrite を使用して、テキストを、GDI や GDI+ のような従来のグラフィックサーフェイス上でレンダリングしながら、配置することができるようになりました。また、必然的に、GDIを使用して、DirectWrite を通してテキストをレンダリングしながら、配置するという、逆のシナリオもサポートされています。互換性に関する第2の側面は、DirectWrite は、GDIで見つかるテキストの配置とレンダリングを行うすべての既存の方法もサポートしているという事実から生じています。DirectWrite アプリケーションは、DirectWrite を使用して、実際に GDI を使用せずにGDI が行う場合と同様に、テキストの配置とレンダリングを実行することができます。この互換モードの下で配置とレンダリングが行われたテキストは、ユーザーの視点からは、GDI テキストと見分けがつかず、GDI テキストと同じように、アプリケーション UI とテキスト文書の既存のレイアウトを維持しています。最後に、DirectWrite は、GDI と相互運用する一連の API を公開しています。GDI フォントオブジェクトを選択しているアプリケーションは、それを DirectWrite のフォントオブジェクトに変換することができます。逆変換も可能です。フォントシステムは、DirectWrite API 層の最低位にあるので、高度なデータの維持と正確さを確保するのに欠かせない最適な相互運用ポイントを提供します。一旦アプリケーションが DirectWrite のフォントオブジェクトを取得できれば、それ以降は、DirectWrite フォントを必要としている他のどの DirectWrite APIでもそれを使用することができます。DirectWrite のフォントオブジェクトからGDIフォントオブジェクトへの再変換機能を使用することで、残りの GDI ベースのアプリケーションを変化なく機能させながら、DirectWrite の新しく改善されたフォントモデルを使用することによる利点を獲得することもできます。実際のいくつかの例のように、Windows 7 の XPS 印刷ラスタライザは、DirectWrite の最上位に実装されており、DirectWrite の相互運用 API を利用し、非XPS プリンタ・ドライバの XPS ベースの印刷ジョブの変換の一部として、GDI フォントへの再変換を行います。また、Windows 7 XPS Viewer は、画面表示のためにGDI+グラフィックレンダリングと同時に、DirectWrite を使用します。

API には説明すべき詳細事項がまだたくさんあります。上記にリンクされているPDCセッションでは、Leonardo Blanco と Kam VedBrat が、DirectWrite と Direct2D、およびこのようなアプリケーションを開発する方法の詳細を説明しています。

Windows NT 3.1 (または後続の API 追加機能)の TextOut や ExtTextOut など、Windows GDI の最初のテキストAPI以降、世界は大きく変わりました。テキストのサポートの進化は、Windows 7の基盤の重要な部分です。私たちは引き続き、グラフィック・オペレーティングシステムのこの最も「基本的な」要素を改善し、テキストをレンダリングするのに用いられる言語、スクリプトまたはデバイスに関係なく、Windows が、開発者にとって非常に有益なツールと API のセットを提供し、エンドユーザーには素晴らしい体験を提供できるようにしたいと考えています。

--Worachai

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

e7blog — Sat, 11 Oct 2008 04:06:27 GMT

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

開発者の方々のために

レイアウトやグラフィックを微妙に調節したり、解像度にあわせてイメージの正確にスケールする必要のあるアプリケーションが最良の結果を出すには、アイテムのピクセル位置を正しく指定することが重要です。これは Mac でも、PC でも変わりありません(http://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 プログラムの互換性プロパティを使用してアプリケーション単位で無効化することもできます。詳細についてはこちらを参照してください。

http://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

High DPI 解像度に対するフォローアップ

e7blog — Tue, 23 Sep 2008 10:00:00 GMT

このブログがもたらす大変素晴らしい点のひとつは、コメントやメールで寄せられるトピックの裏側にある詳細な情報やデータについて、さらに詳しくお話することができる点です。皆様のご質問やご意見についてより深く説明させていただけるのは、非常に喜ばしいことです。今回は、高DPI解像度、アプリケーションの互換性、さまざまなケースでの読みやすさに関する一般的な問題について寄せられたコメントのフォローアップをします。デスクトップ グラフィックス チームのプログラム マネージャーであるRyan Havesonより、グラフィックスとWindows7の関係についてさらに詳しく説明させていただきます。--Steven

私たちがWindows7のプラニングを始めた頃、ディスプレイについてのユーザーデータを調べている際に、非常に興味深い (そして驚くべき) ことを発見しまた。ほぼ半数のユーザーがフルネイティブ画面解像度を使用するためのPC設定を行っていなかったのです。下の表は、以前の記事でChristinaが取り上げたWindows Feedback Program から得られたデータを示したものです。

なぜユーザーが低解像度に設定しているのかを明確に把握する方法はありません。しかし、私たちが目にした多くのコメントは、「高解像度のディスプレイでは、デフォルトのテキストが読みづらいので、低解像度にしているのではないか」、という私たちの仮説と一致していました。もしかしたら、たまたまこのような設定になってしまった、というユーザーもいるかもしれません。例えば、ディスプレイドライバが合っていない、あるいは何らかの理由でアプリケーションが解像度を変更し元に戻らなかった、というケースが考えられます。どんな理由で画面解像度が低くなったにせよ、結果的にぼやけたテキストが表示されてしまいます。PCの画面で長時間このようなテキストを読むと本当に目が疲れます。LCDディスプレイの場合、テキストがぼやけてしまう主な原因は、LCDが固定ピクセルで構成されていることです。これは、非ネイティブの解像度設定では、システムが固定単位の中で断片的なピクセルを表示しなければならないことを意味します。これによってぼやけが生じるのです。ぼやけて見える別の理由は、ディスプレイがネイティブの解像度に設定されていない場合、ClearType text rendering technologyが正しく適用されない、ということです。ClearTypeテキストは、多くの (全てではありませんが) ユーザーに好まれて使用されています。興味深いのは、CRTディスプレイの場合、画面解像度の変更による忠実度の低下が、LCDディスプレイほど強調されないことです。なぜなら、CRTディスプレイは、LCDディスプレイのように固定ピクセルを持っていないからです。ただ、LCDディスプレイは、サイズやコスト面でのメリット、ラップトップPCの人気などの理由により、インストールベースでいち早く市場シェアを獲得しました。非ネイティブ画面解像度で実行するもうひとつの問題は、多くのユーザーが不注意にディスプレイを非ネイティブの縦横比に設定してしまう、ということです。これにより、画像は不明瞭になりしかもゆがんで見えてしまいます。ご想像のとおり、これではさらに目の疲労が悪化してしまいます。

文字以外に目を向けても、このようなシナリオではメディアに対する再現忠実性も同様にいちじるしく損なわれます。多くのユーザーが行っているような設定では、仮にハードウェアがその能力を持っていたとしても、それぞれ1280x720と1920x1080スクリーン解像度にあたる720pや1080pといった高精細(ハイデフ)テレビコンテンツを見ることはできません。PCのモニターは伝統的に「高精細」ディスプレイデバイスでしたが、この問題の解決なしにはこのTV業界に対して持っていたこの優位性を失ってしまう危険性があります。今日、約10%のユーザーだけが真に1080pを表示可能なPCディスプレイを持っているというのは事実ですが、ディスプレイの価格は下がり続け、インストールベースは成長を続ける見込みです。そして、ユーザーが利用したいと望む高精細のコンテンツに対する別の波が来るであろうことも確実でしょう。例として、ディスプレイが400 DPIを獲得したとき、それは紙に印刷された文字と見た目はほとんど区別がつかないでしょう。現在の170 DPI程度のeBookリーダーでもガラスの向こうの紙程度には見えます。

この例から、現実のエンドユーザーが活用できる利点を見ることができます。実はこの問題を解決することができる“High DPI”と呼ばれるWindowsの既存の基盤技術があります。High DPIはWindows 7の新機能ではありません。(初期にもあった基盤技術を超える意味で) VistaまではHigh DPIをサポートするためのOSユーザーインターフェースに対し大規模な投資はされてきませんでした。Vistaで試してみてください。デスクトップ上で右クリックして、個人設定を選び、左側の列から「フォントサイズ(DPI)の調整(J)」を選びます。Windows7に対する私たちの考えは、箱から出したばかりのPCそのままの状態でHigh DPIを利用できるのであれば、ユーザーは高精細エクスペリエンスを利用でき、スクリーン上の文字を読む際の目へのストレスをも大きく減らすことができるのではないかというものでした。ディスプレイの実際のDPIを検知する基盤技術があるので、箱から出したばかりのPCに対するデフォルトの設定の調整で望ましい結果を出すことができます。しかし、こうすることによりhigh DPI設定に対し完全に互換性のないアプリケーションに対し問題が生じる危険性を含んでいます。

問題のひとつは、GDIアプリケーションがDPIを気にしなくてはいけないということです。開発者はウィンドーフレーム、テキストサイズ、グラフィカルボタン、レイアウトをDPI設定で指定されたスケールファクタにマッチさせスケールするようにコードを書かなくてはいけません。そうしていないアプリケーションはいくつかの問題を持つでしょう。大多数は大きな問題ではありません。フォントサイズのミスマッチ、レイアウトに関する些細な問題などです。しかしアプリケーションによっては高DPI設定で走らせたときに大きな問題をおこします。

（この問題を）軽減するいくつかの対策として、例えばDPIを認識しないアプリケーションに対する自働スケーリング機能というような対策を、Windowsに施す事が出来ますが、しかしこうした軽減機能にも問題があります（このテーマに関するGreg Schechter’s blog もご参照ください）。自動スケーリングの場合、DPIを認識しないアプリケーションは、ウィンドーマネージャーによって自動的にスケーリングされます。テキストのサイズは、ユーザーの好みの設定に自動的に合わされますが、結果的に、そのアプリケーションのウィンドーで文字がぼやけるといった影響も生じるでしょう。小さなテキストを読むことができない方々に対して実用的なhigh DPI環境を実現するためには、こうしたスケーリング機能は必要な機能なのです。しかしながら、high DPIにうまくスケールされたアプリケーションだけを使用しているユーザーや、または、テキストサイズがうまく合っていないにもかかわらずその影響をさほど受けていないユーザーは、結果的に自動スケーリングによって文字がぼやける現象が引き起こされる事で、自動スケーリングがより悪い選択肢であると判断してしまうかもしれません。DPIを認識するアプリケーションであるかどうかをOSが検出する方法がないと、デフォルト設定を選択しなければなりません。そしてそれは、どのくらいの利点があるか、何を取捨選択するか、という元の疑問へと立ち返ります。長期的な解決方法は、アプリケーションが解像度に依存しなくなる事と、アプリケーションがユーザーの設定に合わせてスケールできるようにする事です。この為には、私たちのツールとドキュメントの両方のサポートが不可欠です。どうやって時間をかけてそこに行き着くか、そして、いかにその移行期間中の使い勝手を最良なものにするか、これらを見つけ出す事がプラットフォームの挑戦です。

短期的 vs 長期的な顧客満足度

長期的に考えるとhigh fidelity experienceを持たせる事が重要であるという点は、High definition TV（ハイビジョンテレビ）のモデルを見ても明らかです。唯一の問題点は、high DPIの基盤が複数のWindows OSのリリースに渡って存在しているにも関わらず、実際にこれらの環境設定でどのくらいのアプリケーションがテストされたのかを、私たちが明確に把握していない事です。（実際、DPIを認識するアプリケーションの作成方法として2001にMSDNの記事が公開されています。）つまり、この機能を有効にしたことで、より広範囲に引き起こされるであろう短期的なユーザーへの悪影響が数値化されていない事に、私たちは直面しました。私たちがまず初めに行ったことは、起こりえる障害を数値化することでした。私たちは、high DPI設定時にアプリケーションがどのように動作するかを把握する為に、私たちのアプリケーション互換性検証ラボにある1,000を超えるアプリケーションでテストを行いました。そこで私たちが確認できた結果として、これら1000アプリケーションの各問題の比率を以下に示します。

1点補足しますと、私たちが言う“バグ”とは、ソフトウェアが期待にそぐわない動作する事です　‐　つまり、クラッシュといった深刻な問題から、見た目上の問題まで、すべてが対象となります。私たちはこれらのバグを、１～４の段階でその深刻度（Sev）を分類しています。ここでSev1は、本当に深刻な問題（クラッシュ、データ損失、機能の欠落）、そしてSev4は非常に些細な現象、または、非常に発生率が低いものです。

調査の結果、多くのアプリケーションは high DPI において十分動作することがわかりました。ごく一部のアプリケーションでしか主要な機能が損なわれることはありませんでした。もちろん十分動作するアプリケーションは心配の必要がありません。ですがもし 1％のアプリケーションで high DPI において重大な問題があるとすれば、それは重要な数字です。そのため私たちはバグを調査し、発見された問題の種類ごとに分類しています。こちらは私たちが見つけた結果です。

私たちが見つけたことで、もっとも重大な問題のひとつはユーザーインターフェースの表示が欠けてしまうということでした。これをより深く調べると、それらのケースの多くでは画面の有効解像度が極めて低い (800x600 もしくはそれ以下) 時おこるということが明らかになりました。これに基づき、私たちはユーザーがそのような低解像度に設定するケースの数を最小化できるように設定画面をデザインすることができました。私たちは問題の種類を一つ一つ調査し、可能な場合はそれぞれの緩和策をとりました。もちろん最良の緩和策は予防であるため、High DPI は PDC やWinHEC、その他の会合において私たちが開発者の皆さんに対してお話しする重要な焦点になります。

総計 vs 個々のユーザーデータ

私たちの調査のひとつに何人のユーザーが現在 (Vista/XP で) high DPI を利用しているかという事があります。データによると、非常に少ない割合のユーザーだけが現在 high DPI の機能を有効にしています。これを、エンドユーザーはこの機能に関心がない、もしくは必要性がないという明確なメッセージだと安易に捉えることもできます。また別の説明としては、利用されていない主な理由が XP と Vista の high DPI に対するシェルのサポートが非常に限られており、これらのプラットフォームに搭載された IE の各バージョンでフォントサイズが合わなかったりウェブページの比率がおかしくなったりするという大きな問題があるからだという見方もできます。また、Vista以前からこの機能を利用されているユーザーがいらっしゃるという事も理解しています。また再度、私たちはデータを解釈する必要があり、今の段階では必ずしも明白ではありません。

タイミング: この時期にこの機能は市場にとって正しいでしょうか？

幸いなことに、私たちはハードウェアとソフトウェアのどちらが先に出てくるのかといういわゆる “鶏と卵” の問題を抱えていません。ハードウェアはすでにフィールドやマーケットに出ており、したがってOSが単にそれを利用するかどうかという問題だけです。ソフトウェアの観点からすると、多くのソフトウェアアプリケーションは (IE 8 のように改善されたズーム機能をもつブラウザも含めて) DPI に対応できていますが、かなりの数のアプリケーションで high DPI でうまく動作しない可能性があるものが存在しています。別の鍵となるデータとしては、LCD パネルのディスプレイ解像度が標準のDPIでは最大に達しつつあるということがあります。このようなディスプレイで1900x1200を超える解像度にすることはテキストが小さすぎて誰も読めなくなるため、OS の high DPI サポートなしには成し得ません。さらに、既にこの解像度では2 メガピクセルの写真や高精細なビデオ (1080p) を再生することができます。フィールドに既にハードウェアが存在すること、よりよいエクスペリエンスを可能にできる将来性、そしてハードウェアが現状では OS とソフトウェアによって制約されていることを組み合わせると、この件を論じるのは正しいタイミングだといえます。

結論

お客様のデータを調査することは、ウィンドウズエクスペリエンスを改善する方法を見つけるのに役立ちます。この場合私たちが、ユーザーがディスプレイを、メディア再生のための高性能なエクスペリエンスを楽しみ、テキストを適切なサイズに描画させるために設定を簡単にする機会が存在している事が明確にわかりました。とは言うものの、私たちはいつでもウィンドウズアプリケーションのエコシステムに影響を与える可能性の高い機能に投資する場合、皆さんのソフトウェアに対する投資を無駄にしないように注意したいと考えています。また、私たちは、ソフトウェア開発企業の開発者コミュニティと早期に、密にお話し、私たちが提供するプラットフォームの価値を、ソフトウェア開発者の皆さんが彼らのお客様にシームレスに提供できるように確認作業を続けていきます。現在までのところ、マイクロソフト社内のテストや私たちが収集したデータが、私たちが何かを適切に決めるにあたって、非常に重要なデータになっています。High DPI は、エコシステム全体の協力が問題の解決に必要であるという良い例です。また、それは人々が抱えている問題がなにか、それを解決するための最善の方法は何かを判断するために、市場のお客様のデータをマイクロソフト社内のテストとともに、どのように利用できるかという可能性も示しています。

--Ryan

Windows フィードバックプログラム

e7blog — Tue, 16 Sep 2008 10:00:00 GMT

Windows Customer Engineering Feature チームのChristina Storm を紹介します。彼女はテレメトリーと呼ばれている、お客様からのデータ収集を担当しています。

以前のブログで、Steven が Windows 7 Feature チームを紹介しました。私は、Windows Customer Engineering チームでお客様からのデータ収集を担当しているプログラムマネージャーです。私たちのチームは Windows Feedback Program を担当しています。Windows Feedback Program は、開発プロセスにおいてお客様から直接フィードバックをいただくための現在いくつかあるプログラムのひとつです。

Windows Feedback Program (WFP) はWindows XP, Windows Vista のプロダクトサイクルを通して何年も行われてきました。私たちは、現在このプログラムをすべての面において Windows 7 に適用できるよう準備を始めています。このプログラムの最も重要な部分は、私たちのウェブサイト、http://wfp.microsoft.comからプログラムに参加し、登録されているたくさんのお客様を通じての調査です。お客様は、まずアンケートに回答してフィードバックするプログラムに参加するか、または自動化されたフィードバックプログラム参加する、あるいはその両方に参加するかを選択できます。そのあと２０分ほどのプロフィール調査のアンケートに回答していただきます。このアンケートの結果は、フィードバックを後で分析する時の参考にさせていただきます。私たちのプログラムにはコンピューターの知識レベルに関して広い範囲の方が参加されています。そして私たちは参加者のコンピューター知識レベルが偏らないように常に調整しています。私たちのプログラムのようなフィードバックプログラムに自発的に参加される方の多くは、通常テクノロジーに関して非常に熱心な人たちです。彼らは、消費者向け電子機器、デジタル機器、ソフトウェアの新しいバージョンなどを、製品で出た早い時期から使い始める人たちです。対照的に、PCは仕事をするための道具と考えているお客様は、フィードバックプログラムに参加することをあまり好まない傾向があります。または、私たちは、もっと女性の方にプログラムに参加していただきたいと考えています。

自動化されたフィードバックプログラムに参加されたお客様には、Windows Telemetry チームが開発した自動的にデータを収集するツールをインストールしていただきます。このプログラムのプライバシーアグリーメントには、このツールが収集するデータについて記載されています。

いくつかの例をあげます。

Windows およびインストールされ使用されているアプリケーションの使い方
コンピューター上のファイルとフォルダーの構成、およびフォルダーに入っているファイルの種類の数、例えばピクチャフォルダにある JPGファイルの数など
コンピューターにインストールされているハードウェア、デバイス、ドライバや設定などシステム固有の情報
Customer Experience Improvement program (訳注：日本語訳はカスタマエクスペリエンス向上プログラム) のデータ

集められたデータから、Windows フィーチャーチーム、プランナーやユーザーリサーチの専門家が利用するレポートを作成します。以下のチャートは、次の質問の答えを示しています - 「私たちのプログラムに参加するお客様が彼らの PCの中に保存する最も一般的なファイルタイプは何でしょうか? そしてそれらの保存先として最もポピュラーなものは何でしょうか?」

この結果は、プランニングを行う上で私たちがお客様のPCに保存されている大量のデータをいかに取り扱うかを検討するためと、私たちがテストラボで現実と同様のファイル数、ファイルサイズそしてPC上のファイルの位置などのテストシナリオを作成する際に役に立ちます。

更にこれらの収集されたデータにより、私たちはプロファイルされたパネリストに基づくレポートを作成することができます。もし、私たちが私たちのプログラムに参加する2、3の異なったプロファイル、例えば開発者によって提供されたデータに基づいた場合や、ゲームプレイヤーによって提供されたデータに基づいた場合、では上記のチャートは異なるように見えるかもしれません。またWindowsに対する理解度によっても違いが生じるでしょう。従って、自身を Windows のエキスパートであると考えているお客様も、PCは何か物事を成し遂げるためのツールであるとしてとらえ、PCに対して自分たちの時間を費やすことを快く思わないお客様も、私たちにとって大変重要です。データに基づいて、私たちは特定のプロファイルのためにある機能性を最適化することを決定するかもしれません。

一般的に、私たちは、Windowsの次のバージョンで何を改善するべきかについてよりよく理解するために、このデータを利用します。これらのサンプルによって彼らのモニターがどう設定されているか見てみましょう。まず、お客様はどんな解像度でPCを使うでしょう？以下の表はWindows Customer Experience Improvement Program（データ提供に合意したすべてのＰＣをサンプリングしたデータ）に基づく典型的な解像度とその分布をリストしています。（以下の表にはすべての解像度が含まれないので、合計が100%にならない点に注意してください）：　

（約10％のお客様はHD以上の解像度をお持ちです。）

まず気づくことは、およそ10%のユーザーがHDまたはそれ以上の解像度を利用しているということです。いただいたいくつかのコメントの中で、我々のデータは「トップ」か「パワーユーザー」を代表しているのかという質問がありました。サンプルの大きさや、業界をリードする解像度を選択しているユーザーの数を見ると、私はこれが十分にすべてのセグメントを代表しているデータであると合理的に結論づけることができると思います。

このサンプルはとても大きなデータセット（すべてのWindowsのお客様）から取られた、大きなサンプル（データ提供に合意した顧客）であり、従って、セグメント別の研究のために統計学的に有意であるということが言えます。

私たちは、大部分のプログラム参加者が、彼らのディスプレイの最高解像度よりも、表示解像度を下げていることを見出しました。Windows Customer Experience Improvement Programから来るデータと比べてみても、やはり類似した傾向が見られます：1600x1200画面解像度をもつ50%以上のユーザーが解像度を1024x768に調整しています。これは、おそらく、高解像度ディスプレイで小さいテキストを読むことを不快に感じているからでしょう。この解像度変更によるマイナスの影響としては、エディタとウェブブラウザでテキストを読むことが難しいほど、精細さが失われてしまうことです。高解像度ビデオコンテンツは、正しく再現することができません。

これは1600x1200の表示機能があるディスプレイをお持ちのユーザーだけを対象としたデータです：

（68％のユーザーが、1600x1200の表示機能を持つディスプレイで、それよりも低い解像度を使用しています。）

近い将来のブログでは、ディスプレイの品質向上のために、また、快適に文字が読めるように、Windows7において私たちがどんな対応をしたかについて、Windows Desktop Graphicチームのプログラムマネージャーによる解説をご紹介する事になるでしょう。

私たちはまた、これらのデータを頻繁に活用し、アンケートにご参加いただける方を適切に選別する為に役立てています。たとえば、あるリサーチャーが、バーチャルマシンで動作するアプリケーションのユーザーのみを対象として、オンラインアンケートを送信する事に関心を持つ事もあるでしょう。まず、“アプリケーションの使用形態”のデータを調べ、対象となるユーザーを決め、それから、リサーチャー向けに参加ユーザーのリストを作成します。また時には、ユーザー皆様の全体的な満足度とPCの環境設定情報との関連性を解析するために、私たちは自動的に収集したデータをアンケートの返信情報に結びつける事を行っています。

現時点、私たちの調査パネル参加者の50％が、Windows XPを使用し、50％が Windows Vistaを使用しています。また現在、この調査パネルは、自由にご参加いただける形体にはしておりません。もし、お客様がこのプログラムに参加される事にご興味をお持ちでしたら、こちらのメールアドレスにご連絡ください； winpanel@microsoft.com　（件名に“Notify me for enrollment”とご記入ください）。また、Windowsの知識をどの程度お持ちかといった、お客様自身の情報をほんの少しでもご提供頂けるなら、私たちはそのご協力に非常に感謝致します！お客様を参加登録待ちリストに追加し、参加枠が空きしだいご招待差し上げる様、最大限努力致します。

Windows 7のベータ版をリリースした後も、Windows 7 ベータ版をご使用になられているお客様へ対し、調査パネルへの参加のお願いと、調査パネルからのフィードバック収集を行う予定です。なお、ベータへのサインアップのご案内は、Microsoftのこれまでの方法と同様に、http://connect.microsoft.comより実施する予定です。お見逃しなく！

-- Christina Storm