Windows 8ではiPhone 4級の高画素密度を想定せよ：BUILD（1/2 ページ）

[本田雅一，ITmedia]

　米カリフォルニア州アナハイムで開催されているMicrosoftのソフトウェア開発者向け会議「BUILD」は、開催半ばを超えて落ち着きを見せている。各テクニカルセッションでは、エンジニアたちがMetroスタイルの新しいアプリケーションを構築する方法について学んでいるが、多くは開発者による開発者のための情報だ。

　そうした中から個人的に気になっていたテーマを追ってみた。それはさまざまな形状、サイズ、解像度のディスプレイに対する適応性だ。またフルスクリーンで動作するMetroスタイルアプリケーションとマルチディスプレイ環境の親和性についても触れたい。

表示サイズと解像度の束縛から脱出するWindows 8

　画面サイズが変わっていないのにディスプレイの画素数が向上すると、（ドットピッチが狭まり、表示が細かすぎて）かえって使いづらくなる。これはWindowsだけでなく、Mac OSも抱えてきたジレンマだ。PCの内部処理上の解像度は、もともとブラウン管を用いたCRTディスプレイを前提にしたものだった。CRTの表示密度には限界があったため、内部処理の解像度に柔軟性を持たせる理由はあまりなく、ソフトウェア開発においても重要視されることはなかった。

　これが問題の発端。

　ところが液晶の時代になり、画素数を上げることが容易になってくると、ディスプレイの画素数を上げたくとも、表示が小さくなりすぎるなどの理由で上げられなくなってしまった。表示位置やサイズを画素数で指定していたり、レイアウト設計しているアプリケーションなどがあったためだ。

　そこで解像度への依存を下げるように開発者へお願いをした上で、Windows側でも多様な解像度に対応できるようユーザーインタフェース設計のやり直しをしてきた。その結果、ある程度は問題も解決してきているのだが、まだまだ完全解決には至っていないのが現状だ。

　実はこの問題を解決するチャンスは、かつてLonghornと呼ばれていたWindowsにあった。ここでは描画の仕組みが根本から見直され、以前のアプリケーションとの互換性はスケーリング表示で対応しようとしたのだが、システムの構成が二転三転したことや旧来のアプリケーションの表示品質などの問題もあり、結局、高画素密度ディスプレイへの本格対応には至らなかった。同様のトライはMac OS Xでもあったが、こちらも問題は解決していない。

スケーラブルな表示の重要性を訴えるマイクロソフト。解像度を情報量増加だけでなく、美しさへと活用できるようになる

　しかし、Metroスタイルアプリケーションを作るためのWinRTは、従来のデスクトップとは異なる枠組みで、しかも全アプリケーションがフルスクリーン表示となる。これならば、しがらみを捨てて画素数に依存しない画面表示を行える。

　MicrosoftはMetroスタイルアプリケーションの開発ツールにおいて、部品のグラフィックス要素をSVG、CSS、XAMLで記述したベクトルグラフィックスとした上で、ビットマップ部品に関しても3種類の解像度（100％、140％、180％。100％は96dpi）を用意した。拡大縮小で品質劣化のないベクトルグラフィックスを強く推奨している。

　さらに「高解像度ディスプレイはすぐに出てくる。すでに200dpi（ppi）程度のディスプレイはあるし、250dpiを超えるウルトラ高解像度のディスプレイもWindows 8が出るころには珍しいものではなくなる」と警告し、開発者に意識するように促していた。「iPhone 4並の高画素密度のPC画面を想定せよ」ということだ。

スケーラブル表示に対応するため、Metroの開発テンプレートはベクトルグラフィックスや複数解像度のビットマップ部品で構成されている（写真＝左）。高解像度のスケーラブル表示に対応するMetroスタイルの部品群（写真＝右）。すべてベクトルグラフィックスでできている

　このため、Metroスタイルのアプリケーションは解像度次第で、解像度を情報量増加か、あるいは表示品位の向上、いずれでも活用できるようになっている。デスクトップアプリケーションも併存するため、従来型の端末では極端な解像度は選べないだろう。しかし、タブレット型などMetroスタイルでの利用を中心に考えるならば、より高い解像度で品位を上げるという“画素数の使い方”が可能になる。

　そしてこれは、多様な機器を1つのアーキテクチャで統合するWindows 8自身にとっても、とても重要になってくる。Windows 8はPCだけのOSではないからである。初日の基調講演に引き続いて行われた、参加者全員を対象にした説明でも解像度に依存しないプログラムの作成は、最優先事項の1つとして伝えられたことを報告しておこう。

かつてない多様な形状、サイズ、解像度をサポートするWindows 8

　一方、BUILDが始まる前は「Windows 8は16：9の画面しかサポートしない」とのうわさが流れていた。しかし、実際には他のアスペクト比でも問題なく使えるように設計されている。

Windows 8は多様な画面サイズと解像度、アスペクト比に対応する

　Windows 8がサポートする最低画素構成は1024×768ドットの、いわゆるXGA。これ以上であれば、Metroのデザインバランスや操作性を損ねずに使えるという最低条件だ。つまり、4：3のアスペクト比でも動くことになる。この場合、上下はいっぱいに使われるが、左右方向がやや切れる形になる。

　それでは、いまや少数派になりつつあるPC向けのワイドアスペクト比、16：10のサポートはどうだろうか。この場合、上下に若干の黒い帯が描かれ、その間に16：9のスクリーンが描かれることになる。残念？　そうかもしれない。この理由については、後ほど述べることにしよう。

　そして16：9ならば、余り領域なしの全画面ワイド表示となる。この辺りが、Windows 8は16：9でしか使えないという、うわさの元になっているのだろう。しかし、動く、動かないのレベルであれば、どのアスペクト比でもちゃんと動いてくれる。

　縦横の比率も違えば、サイズも違う。7型程度のタブレット端末と27型の高解像度ディスプレイでは、画素密度も違えば使用スタイルも違う。前者はタッチパネルで手持ちだろうが、後者は机の上でキーボードとマウスを使って操作することが多い。

　さらに前述したように画素密度の制限から解放されるため、中長期的に見ると高精細化がより進んでいくことは間違いない。Windowsにおける標準の内部処理解像度は96dpiだが、200〜300dpiぐらいのディスプレイも出てくるだろう。

Metroアプリケーションの開発者が意識すべきアスペクト比の一覧

　このように緩い規定で、多様な形状、多様なサイズ、多様な解像度のディスプレイに対して、どのようにアプリケーションをデザインすればいいのか。

　タイルを使ったリスト表示などは、Windows 8のシステム側が自動的にレイアウトしてくれるが、画面全体のデザイン、レイアウトは開発者自身が考えなければならない。途方もない組み合わせのデザイン設計が必要に感じるかもしれないが、実は考え方はシンプルだ。

　メインの操作画面について、ミニマム（4：3）とワイド（16：9）の2つのアスペクト比を考慮したデザインが求められる。さらに縦表示に回転させた場合のレイアウトも必要になる。この3つのアスペクト比で画面設計を行えば、どのWindowsシステムでも表示が崩れることはない。