Honeycomb 上的画布/位图和 alpha 混合性能问题 (TF101)

发布于 2024-12-02 18:41:24 字数 852 浏览 2 评论 0原文

我第一次尝试使用 android 2D API(我在这里学到了很多),在使用 alpha 混合时,我注意到我的 Honeycomb 平板电脑(TF101)上出现了一些令人担忧的性能问题:

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

上面的代码是使用众所周知的 SurfaceView 渲染的/线程对。 bmBackground 是 RGB_565,bmForeground 是可变的 ARGB_8888,paint p 仅用于使用 alpha。两个位图都是全屏的。

在我的 Nexus S 和 Galaxy S (Gingerbread) 上,无论我为 p 设置多少 alpha 值,也无论 bmForeground 的像素格式(RGB_565 或 ARGB_8888)如何,渲染都以 55 fps 运行。

但在我的 Honeycomb 平板电脑上,我有一些奇怪的行为:

  • 60 fps,alpha 禁用 (= 0)
  • 10 fps,0 <<阿尔法< 255
  • 20 fps,p = null
  • 60 fps,bmForeground = RGB_565

使用 alpha 混合和/或从 ARGB(位图)转换为 RGB(帧缓冲区)时,驱动程序似乎存在一些性能问题?

我已经了解 OpenGL 解决方案,但我想了解这里发生的情况,并找到解决它的方法。

太棒了,运行在 1GHz 的双核设备无法比我的 Galaxy S 绘制 2 个位图做得更好!我错过了什么吗?

I'm in my first tries with the android 2D API (I learned a lot here), and while playing with alpha blending I noticed some worrying performance issue on my Honeycomb tablet (TF101) :

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

The code above is rendered using the well known SurfaceView/Thread couple. bmBackground is RGB_565, bmForeground is a mutable ARGB_8888, the paint p is for playing with alpha only. Both bitmaps are full screen.

On both my Nexus S and Galaxy S (Gingerbread), the rendering is running at 55 fps whatever the alpha value I set for p, and whatever the pixel format for bmForeground (RGB_565 or ARGB_8888).

But on my Honeycomb tablet, I've some strange behaviour :

  • 60 fps with alpha disabled (= 0)
  • 10 fps with 0 < alpha < 255
  • 20 fps with p = null
  • 60 fps with bmForeground = RGB_565

It seems that the driver have some performance issue when using alpha blending and/or converting from ARGB (Bitmap) to RGB (framebuffer) ?

I already know about the OpenGL solution, but I'd like to understand what's happening here, and to find a way to solve it.

That would be awesome that a dual core device running at 1GHz can't do better than my Galaxy S drawing 2 bitmaps ! Am I missing something ?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

别挽留 2024-12-09 18:41:24

不存在驱动程序问题,使用 Canvas 渲染到 SurfaceView 上完全是在软件中完成的。拥有 2 个核心甚至 1 Ghz 并不一定有帮助,对于位图来说,大多数时候最重要的是内存带宽,而 Galaxy S 在这方面确实很擅长。

您还假设您的帧缓冲区是 RGB,但您没有指定哪个 RGB(RGBX 8888 或 RGB565?) 您如何创建 SurfaceView?最小化转换非常重要(如果您的 SurfaceView 是 RGBX 8888,请不要使用 RGB 565 位图,如果您的 Surface 是 RGB 565,请避免使用 RGBA 8888 位图等)

您也没有提及您的位图有多大?如果您的两个位图都是全屏位图,并且您的平板电脑具有与 Motorola Xoom(基于 Tegra2)相同的架构,那么您获得的性能并不意外。

There is no drivers issue, rendering with a Canvas onto a SurfaceView is done entirely in software. Having 2 cores or even 1 Ghz don't necessarily help, what matters most of the time with bitmaps is the memory bandwidth and the Galaxy S is really good at that.

You are also making the assumption that your framebuffer is RGB but you don't specify which RGB (RGBX 8888 or RGB565?) How do you create your SurfaceView? It is very important that you minimize conversions (if your SurfaceView is RGBX 8888, don't use RGB 565 bitmaps, if your surface is RGB 565, avoid using RGBA 8888 bitmaps, etc.)

You also fail to mention how big your bitmaps are? If both your bitmaps are fullscreen bitmaps, the performance you are getting is not unexpected if your tablet has the same architecture as a Motorola Xoom (Tegra2 based.)

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文