Metal Best Practicesは、iOS／MacOS／tvOSのAPIであるMetalを用いた設計のベストプラクティスガイドです。
本稿では、何回かに分けてこのガイドを読み解き、コード上での実験を交えて解説していきます。
読んでそのまま理解できそうなところは飛ばしますので、原文を読みながら原文のガイドとしてご利用下さい。
また、iOSの記事なので他のOS(MacOS, tvOS)についての記載は割愛します。
他の記事の一覧は、初回記事よりご覧下さい。
Native Screen Scale (iOS and tvOS) (画面スケール)
ベストプラクティス： ターゲットディスプレイの正確なピクセルサイズでドローアブルをレンダリングします。
不要なレンダリングや、テクスチャーサンプリングによるパフォーマンス低下を避けるために、ドローアブルのピクセルサイズはデバイスの物理的なピクセルサイズと同じにしましょう、という話です。
前提として、iOSにおいては、画面の描画のサイズは基本的にポイント単位で指定しますが、Metalではピクセル単位で指定するということがあります。
そのため、ドローアブルのピクセルサイズを計算するためには、UIScreenのプロパティから、ネイティブの画面サイズをnativeBoundsから、スケールファクター（1ポイントが何ピクセルに対応するか)をnativeScaleから取得する必要があります。
なお、MTKViewを用いた場合、ドロアーブルのサイズはビューのサイズと常に一致することが保証されるので、このあたりの計算を自分でする必要はありません。
結論
ドローアブルの領域が広ければ、レンダリングに時間がかかることは自明なので、まぁそうだろうなというところです。自明なことなので、今回は、サンプルコードを作って試していません。
軽く手元で試してみた限りでは、同じ1000x1000の画像を1000x1000のドローアブルに描画するのと、2000x2000のドローアブルに描画する（余った領域は空白になる）のでは、やはり1000x1000の方が高速に描画していました。
最後に
iOSを使った3D処理やAR、ML、音声処理などの作品やサンプル、技術情報を発信しています。
作品ができたらTwitterで発信していきますのでフォローをお願いします🙏
Twitterは作品や記事のリンクを貼っています。
https://twitter.com/jugemjugemjugem
Qiitaは、iOS開発、とくにARや機械学習、グラフィックス処理、音声処理について発信しています。
https://qiita.com/TokyoYoshida
Noteでは、連載記事を書いています。
https://note.com/tokyoyoshida
Zennは機械学習が多めです。
https://zenn.dev/tokyoyoshida