デスクトップ ソフトウェア用の GUI を開発し、Web サイトを開発するとき、事実上すべての解像度で適切に動作し、スケーリングされるはずのものを開発していると思いました...アプリのウィンドウのサイズを変更したり、高解像度または低解像度のディスプレイに表示したりすると、適切にスケーリングして表示する必要があります (たとえば、StackOverflow は幅 960 ピクセルのコンテナーを使用します)。
Web 開発者の観点から、固定幅の Web サイト (通常は 940 から 1000 ピクセルの範囲) を開発するように求められることがよくありますが、それらはまったくスケーリングされません。このような Web サイトはたくさんありますが、多くのアプリはサイズが大きくなるように設計されていません。
また、サイズが大きくなるアプリは通常、解像度が大きいほど画面も大きくなることを期待しているため、メインのアプリケーション パネルを引き延ばすだけで完了します。
ここで、「Click me」という 150x50 のボタンのような静的要素を考えてみましょう。このボタンは大きくすることを意図しておらず、通常の 1440x900 ディスプレイで問題なく使用できます。Retina スクリーンの解像度は 2580x1800 になりました。アプリは解像度の変更を確認しますが、「ねえ、そのユーザーは巨大な画面を持っているに違いない」と考えているため、ボタンを同じサイズに保ちます。
ここで発生する問題は、両方の解像度が同じ 13 インチの画面に適用されるため、ボタンが元のボタンのサイズの一部に見えることです。ユーザーの視覚によっては、ボタンが読めない可能性があります。マウスの設定によっては、クリックしにくい場合があります。
この問題を解決するために、Apple と Microsoft は 2 つの異なるソリューションを使用しました。
- Microsoft は、ディスプレイの解像度が 2580x1800 であるが、ユーザーがすべてを 200 dpi にスケーリングすることを望んでいることをアプリに通知することにしました。これは、アプリがガイドラインに従っていない場合、アプリが小さく見えることを意味します。多くのアプリは DPI 設定を単純に無視します (ただし、これは Windows 8 では変更される可能性があります)。
- Apple は、モニターの解像度が 1440x900 であることをアプリに報告することを決定しましたが、要求があれば、より高解像度の要素を表示できるとのことでした。つまり、新しい Retina 設定の前に存在するアプリは、エンド ユーザーには以前と同じサイズに見えますが (デフォルトの Apple API を使用すると、テキストがより鮮明になるなどの利点が追加されます)、高 DPI を提供することを決定できます。ディスプレイ上ではるかによく見える画像。
どちらのソリューションもアプリがディスプレイが高 DPI (「網膜」) であることを認識している必要がありますが、Apple がそれを処理した方法は、前述の静的な Web サイトとアプリが非常に鮮明で高解像度でないことを除いて、問題なく表示されることを意味します。使用する解像度の画像。また、Retina 機能にオプトインするには、たとえば 100x100 のキャンバスに 200x200 の画像を提供する必要があり、残りは Apple が処理します。
