Android GLES20 big textured quad very slow (on Nexus One)

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 开发者_JS百科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?

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 ...

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.