ハニカムのキャンバス/ビットマップとアルファブレンディングパフォーマンスの問題（TF101）

Question

私はAndroid 2D APIを最初に試しています（ここで多くのことを学びました）。AlphaBlendingで遊んでいるときに、Honeycombタブレット（TF101）で心配なパフォーマンスの問題に気付きました。

canvas.drawBitmap(bmBackground, 0,0, null);                     
canvas.drawBitmap(bmForeground, 0, 0, p);

上記のコードは、よく知られているSurfaceView/スレッドカップルを使用してレンダリングされます。 BmbackgroundはRGB_565、BmforeGroundはMutable Argb_88888で、ペイントPはアルファのみで遊ぶためです。両方のビットマップはフルスクリーンです。

私のNexus SとGalaxy S（Gingerbread）の両方で、レンダリングは、私がPに設定したアルファ値が何であれ、BMFORGRAND（RGB_565またはARGB_8888）のピクセル形式が何であれ、55 fpsで実行されます。

しかし、私のハニカムタブレットでは、私はいくつかの奇妙な振る舞いをしています：

• Alpha Disabledを備えた60 FPS（= 0）
• 0 <alpha <255の10 fps
• p = nullの20 fps
• bmforeground = rgb_565の60 fps

ドライバーは、アルファブレンディングを使用したり、Argb（BitMap）からRGB（FrameBuffer）に変換したりする際にパフォーマンスの問題を抱えているようですか？

私はすでにOpenGLソリューションについて知っていますが、ここで何が起こっているのかを理解し、それを解決する方法を見つけたいと思います。

1GHzで実行されているデュアルコアデバイスが、Galaxy S Drawing 2ビットマップよりも優れていないことは素晴らしいことです！私は何かが足りませんか？

Answer 1

ドライバーの問題はありません。Canvasを使用してSurfaceViewにレンダリングすると、完全にソフトウェアで行われます。 2つのコアまたは1 GHzさえも必ずしも役立つとは限りませんが、ビットマップでほとんどの時間が重要なのはメモリ帯域幅であり、Galaxy Sは本当に良いです。

また、FrameBufferがRGBであると仮定していますが、どのRGB（RGBX 8888またはRGB565）を指定していませんか？コンバージョンを最小限に抑えることは非常に重要です（SurfaceViewがRGBX 8888の場合、RGB 565ビットマップを使用しないでください。SurfaceがRGB 565の場合は、RGBA 8888ビットマップの使用を避けてください）

また、ビットマップの大きさについても言及できませんか？両方のビットマップがフルスクリーンのビットマップである場合、タブレットがMotorola Xoom（Tegra2ベース）と同じアーキテクチャを持っている場合、あなたが得ているパフォーマンスは予想外ではありません。