最大 5 つの大きな UIView を作成しています。UIView は画面の高さいっぱいで、幅は何倍にもなります。各レイヤーは異なる速度でスクロールしますが、すべて再利用される UIImageViews のタイル化されたコレクションが含まれています。
各ビューのどの部分が画面上にあるかを常に見つけ、表示されているタイルを UIImages に非同期にロードしてから、メイン スレッドの UIImageView にイメージを設定します。(これには NSOperation を使用します。)
iPad 2 では非常にスムーズに動作するようになりました。それから iPad 3 を手に入れて接続したところ、パフォーマンスはひどいものでした。スクロールしている間ずっと、わずかなしゃっくりまたは完全な遅延が発生します。
これは、Retina ディスプレイで行われている大量のアルファ ブレンディングが原因であると考えられます。
CATiledLayer を試してみたところ、スクロール モーションの問題は修正されましたが、タイルの読み込みが非常に遅くなりました。（新しい画像が完全に読み込まれるたびに setNeedsDisplay を呼び出していましたが、それでも遅いです。）
パフォーマンスに役立つと思われる変更を 3 つだけ見つけました。
私の UIViews は、多くの列を持つ 1 つの行に分割されていました。各列は、デバイスの高さ全体で 128 ポイント幅でした。画像を 2 行に分割しました。上の行は 128x512 ポイント、下の行は 128x256 ポイントです。（私は常に横向きでiPadのみなので。）
完全に透明なピクセルのみを含むタイルが nil 化されていることを確認して、ブレンドに寄与しないようにしました。
階層化された UIView の数を減らしました。また、スクロール ビューのサイズを縮小しました。つまり、タイルを画面の上部 2/3 にのみロードしました。
ポイント 2 と 3 は、アプリがブレンド操作を実行する必要がある全体のピクセル数を減らすために機能します。
しかし問題は、それらが妥協であることです。iPad2で非常にスムーズに動作しているときに、このように妥協し始める必要はありません.
私の質問は次のとおりです。画像のブレンドパフォーマンスを向上させるためにできることはありますか? このために OpenGL の外にとどまりたいのですが、OpenGL に行くと完全に書き直すことになり、コードは UIKit でより速くまとめられ、さらに UIScrollView でよりうまく機能します - スクロールはギミックのようなものだからですこれで、UIScrollView のネイティブな動作を維持できれば素晴らしいことです。
ですから、PNG 透明度を魔法のように高速にブレンドする方法がわからないこと、または iPad 3 でプロセスを最適化する別の方法があることを願っています。ありがとう!