Are OpenGL Textures more memory efficient than Android Bitmaps?

Question

I have a custom application that deals with many Bitmaps tiles that are 256x256 images (png,jpg). I'm currently using the View 2d canvas and bring in all images as RGB_565. Although I'm generally happy with the applications performance, I have features I'd like to add that will require even more map tiles (Bitmaps). I've been thinking about using opengl ES 2.0 but am fairly new to it.

• Would opengl Textures be more memory efficient than keeping Bitmaps around? I assume you can load a Bitmap into a Texture and then dispose of the Bitmap

• Is it an acceptable practice in opengl to dynamically load many different Textures at runtime?

• Do you need to cache Textures or does the GPU handle that for you?

Answer 1

• Would opengl Textures be more memory efficient than keeping Bitmaps around? I assume you can load a Bitmap into a Texture and then dispose of the Bitmap

Maybe they are and maybe they're not. The one thing that OpenGL would give you is the ability to use compressed texture formats (usually one of the DXTn formats). If you don't care about an alpha channel (or if 1 bit alpha is enough) this can get you one-eighth of the storage requirements; if you do it can be one-quarter. Whether or not this is a win compared to your current PNG/JPG approach depends a lot on whether you're keeping uncompressed variants of your image file in memory too.

There is dependency on your driver supporting compressed textures too; if it doesn't it's game over. There's also a (slight, but depends on the texture) quality tradeoff involved here.

Brief summary here: http://developer.motorola.com/docstools/library/understanding-texture-compression/

• Is it an acceptable practice in opengl to dynamically load many different Textures at runtime?

That can be slow and it's one of the tradeoffs of using a 3D API for this. On the one hand you get to store textures in high-performance local video memory; on the other hand it can take a little time to get them there. Generally what you'd do (in this case - if storage wasn't a problem you'd just load everything up-front) is create a small handful of textures at the required size (256x256 in your case) then use glTexSubImage2D (or glCompressedTexSubImage2D for compressed textures) to update the data; that way the only hit you incur is disk I/O and bandwidth; otherwise OpenGL will be throwing away the old texture and completely re-specifying a new one each time.

With compression available respecifying a texture can be as little as 5 lines of code - fopen, fread, fclose, glBindTexture and glCompressedTexSubImage2D.

Of course you would also store the source textures on disk in the native compressed format so that they can be uploaded directly instead of having to go through any intermediate conversion steps (that will also be a huge saving in terms of performance on your current PNG/JPG usage, which would require the image files to be decompressed and converted to 5-6-5 first).

• Do you need to cache Textures or does the GPU handle that for you?

The GPU will do that for you. Just create a texture object using glGenTextures to give it a unique name, then glBindTexture that name in order to use it, and the GPU will manage everything else.

So - compressed textures, update existing textures rather than respecify, and you should see some improvements in both memory usage and performance.