2

私たちの製品には、画面にすばやくコピーする必要があるフルフレームのピクセル データを基本的に生成する一種のソフトウェア イメージ デコーダーが含まれています (iOS で実行しています)。

現在、CGBitmapContextCreate を使用しており、メモリ バッファーに直接アクセスしてから、フレームごとに CGBitmapContextCreateImage を呼び出し、そのビットマップを画面に描画します。これは、まともなフレームレートで iPad の Retina ディスプレイのフルスクリーン リフレッシュを行うには遅すぎます (ただし、非 Retina デバイスでは問題ありませんでした)。

glTexImage2D と glTexSubImage2D (本質的にテクスチャにレンダリングする) の使用を含む、あらゆる種類の OpenGL ES ベースのアプローチを試しましたが、CPU 使用率は依然として高く、フルスクリーン リフレッシュで ~30 FPS を超えることはできません。問題は、30 FPS では、ピクセルを画面にコピーするためだけに CPU 使用率がほぼ 100% になることです。つまり、CPU で独自のレンダリングを行うための作業があまりないことを意味します。

私たちは OpenGL や最大のパフォーマンスを提供する iOS API を使用することにオープンです。ピクセル データは 32 ビット/ピクセルの RGBA データとしてフォーマットされますが、ある程度の柔軟性があります...

助言がありますか？

4

4 に答える 4

1

CoreVideo は、検討すべきフレームワークである可能性が最も高いです。OpenGL と CoreGraphics のアプローチでは、ビットマップ データをメイン メモリから GPU メモリに移動するコストに大きな打撃を受けています。このコストはデスクトップにも存在しますが、iPhone では特に苦痛です。

この場合、ボトルネックはテクスチャ データのコピーであるため、OpenGL は CoreGraphics よりも大幅に高速化されません。OpenGL により、より効率的なレンダリング パイプラインが得られますが、テクスチャ コピーによってすでに損傷が生じています。

そのため、CoreVideo が最適です。私がフレームワークを理解しているように、それはあなたが直面しているまさにその問題を解決するために存在します。

于 2016-09-12T23:03:50.050 に答える
1

数年後、この必要性に遭遇したさまざまな状況で、iOS 用の基本的な「ピクセル ビューアー」ビューを実装することにしました。32 bpp RGBA、24 bpp RGB、いくつかの YpCbCr 形式など、さまざまな形式のピクセル バッファーの高度に最適化された表示をサポートします。

また、スマートスケーリング、フィット/フィルへのスケーリングなどのために、すべての UIViewContentMode* をサポートしています。

コードは (OpenGL を使用して) 高度に最適化されており、iPhone 5 やオリジナルの iPad Air などの古い iOS デバイスでも優れたパフォーマンスを発揮します。これらのデバイスでは、24bpp フォーマットを除くすべてのピクセル フォーマットで 60FPS を達成しますが、24bpp フォーマットでは約 30 ～ 50 fps を達成します (私は通常、デバイスのネイティブ解像度でピクセル バッファーを表示することでベンチマークを行っているため、明らかに iPad は iPhone よりもはるかに多くのピクセルをプッシュする必要があります。 5)。

EEPixelViewerをチェックしてください。

于 2016-09-12T00:01:42.807 に答える
0

その後、pbuffer または FBO をテクスチャ マップとして使用して、OpenGL ES でさらにレンダリングすることができます。これは Render to Texture または RTT と呼ばれます。EGL での pbuffer または FBO の検索がはるかに高速

于 2012-07-11T01:59:12.933 に答える