Assuming you are using shaders, test the alpha value of your sample, pick a good number (i don't know how much alpha blending you have) and any fragment whose alpha is below that, just discard.

1st gen iPads are a nightmare for fill-rate. Switching to PVRTC will help.

If your texture allows it, then identify areas which don't need to be filled, and use trade extra geometry for less fill-rate. You could even take that to an extreme, assuming we're talking about concentric hexagons visible in this image (http://shogun3d.net/images2/looptil/04.jpg), then the performance will be massively better if they are rendered as geometry with no texture whatsoever. A thousand or so extra triangles is nothing compared to the hundreds of thousands of pixels you'll avoid filling.

What I ended up doing was rendering 4 quads to avoid drawing the area that was fully transparent. Now I get 60fps majority of the time.

I'm going to try compressing it to use PVRTC soon, because I'm using RGBA8, which i know isn't too optimal, especially since it's black and white.

If that texture is greyscale + alpha, you are currently using 2x the memory bandwidth by loading it as a RGBA8. The win from downsizing that to 2 channels is likely to overshadow any gains due to texture compression.

Convert to a LUMINANCE_ALPHA 2-channel setup, and compress it, and you should be cooking (although, as other posters have mentioned, any large holes should be created with geometry, not alpha).

I have yet to compress the texture (haven't looked into how to do so yet). The large hole created with geometry worked.

You said "overlay" which implies you are blending the whole thing on top after the rest of the stuff. Instead render it as a background, glDisable(GL_BLEND).

And then make the yellow bar and whatever else glEnable(BLEND), you will be blending much much less pixels. And even your black text, obviously nothing blends with black, so when drawing black objects dont blend with the background. You should see the same exact results.

That defeats the purpose of the overlay image altogether. Without the alpha blending, it looks awkward and isn't desirable.

Also as the other guy suggested about holes: Any 100% transparent pixels should be alpha tested out so that they dont blend in. use GL_ALPHA_TEST and GL_BLEND together.

Alpha testing on mobile devices is generally slower, and should be avoided. This is what I've read many times while googling iOS optimizations. Second, I'm using OpenGL ES 2.0, and it doesn't appear that GL_ALPHA_TEST is supported. Gives me an error when I try to enable it because it's not defined.

Anyway, it's working at acceptable speeds now. Next I'll do some further optimizations such as texture compression, etc.

Shogun.

Yea I forgot about alpha test. The overlay you missed my point completely.

.5*healthbar + .5*your_background texture == .5*your_background texture + .5*healthbar

If you put the background drawn first, without alpha blending, it will be in the background. If you blend your health bar on top, the amount of pixels you are blending is only the health bar pixels. (A lot less pixels blending).

I'm not sure that would work that well...

Maybe with constant alpha, but not with an alpha channel.

First you would also need to modify your blending function, and make sure your framebuffer is RGBA.

Normally you do srcA * srcRGB + (1-srcA)*dstB.

If you want to to it the other way around, you have to blend with (1-dstA)*srcRGB + dstA*dstRGB in your second pass, to use the alpha in the overlay.

I think It also requires that the game graphics can't have an alpha channel of their own, so no smooth edges. (like those clouds)

I have yet to compress the texture (haven't looked into how to do so yet).

It is literally dead simple. Fire up texturetool on the command line, and profit.

I've never heard of texturetool. Does it come with XCode or something? Let me google that.

Shogun.