Android GLES20 大纹理四核非常慢（在 Nexus One 上）
我仅使用 GLES20 上下文渲染覆盖整个表面的 2 个三角形。现在的问题是，以这种方式仅绘制一个纹理似乎速度慢得不合理。帧速率从 58 fps 下降到 21 fps。
- 问题确实似乎是所有四边形一起绘制的整体像素区域
- 位图在加载时调整为pow2
- 使用8888或565位图以正确的内部GL格式加载位
- 图不会改变任何
- 顶点和片段着色器代码绝对是最小的
- 启用/禁用混合不会改变任何
- 在一个图块或多个图块中绘制整个位图没有帮助的
- glDrawTexiOES似乎不适用于GLES20（GL枚举错误）
我在这里不知所措；我认为在 GL 中位图传输单个图像应该至少与在 Canvas 中进行相同的操作一样快，但情况似乎并非如此。
有人可以提供有关此性能影响的提示或解释吗？
更新：
我刚刚调整了渲染线程以支持画布而不是 EGL 上下文和我做的完全一样；显示 fps 文本和位块传输 背景纹理。 你猜怎么着：仅显示文本我得到 58fps，添加背景 我得到的图片... 57fps！
现在我正式非常生气了。我希望我是 只是不够聪明，不能很好地使用GLES20，否则似乎如果 你想要 blit 2D 图形 - 你使用 Canvas；当且仅当你 想要很多 3D 三角形，那么你就采用 OpenGL。
OpenGL 不应该总是至少与 2D API 提供的一样快吗？ 画布？
I render 2 triangles covering the whole surface using GLES20 context only. The problem is now that drawing just one single texture this way seems to be unreasonably slow. The framerate goes down from 58fps to 21fps.
- the problem really seems to be the overall pixel area drawn of all quads together
- bitmaps are resized to pow2 on loading
- bitmaps are loaded with correct internal GL formats
- using 8888 or 565 bitmap doesn't change anything
- both vertex and fragment shader code is absolutely minimal
- enabling/disabling blending doesn't change anything
- drawing whole bitmap in one tile or in multiple tiles doesn't help
- glDrawTexiOES doesn't seem to work with GLES20 (GL enum error)
I'm at a loss here; I thought blitting a single image in GL should be at least as quick as doing the same with Canvas, but it doesn't seem to be the case.
Can someone provide tips or an explanation of this performance hit?
Update:
I just adapted my rendering thread to support a canvas instead of EGL
context and I do absolutely the same; showing an fps text and blitting
a background texture.
Guess what: showing the text only I get 58fps, adding the background
picture I get... 57fps!
Now I am officially and very seriously pissed off. I hope that I am
just not smart enough to use GLES20 well, otherwise it seems that if
you want to blit 2D graphics - you take Canvas; and if and ONLY IF you
want many triangles in 3D, then you take OpenGL.
Shouldn't OpenGL be always at least as fast as the 2D API provided by
the Canvas?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这可能是由于纹理尺寸较大且没有 mipmap（因为这样内存访问无法得到很好的优化），或者是由于纹理不是 2 的幂（因为这样地址计算会更困难 - 需要使用乘法）而不是轮班）。
希望这有帮助...
this is probably caused by large texture size and no mipmaps (because then the memory accesses can't be optimized very well), or by the texture not being power-of-two (because then the address calculation is harder - need to use multiply instead of a shift).
Hope this helps ...
无意冒犯，但将全屏纹理从 58 fps 提高到 57 fps 也不算太糟糕。无论是 2D 还是 3D，手机或平板电脑的 CPU/GPU 始终会受到填充率的限制。
No offense, but going from 58 to 57 fps for a fullscreen texture is not too bad. Whether 2d or 3d a phone or tablet cpu/gpu will always be fillrate limited.