Using GL_UNSIGNED_SHORT_1_5_5_5_REV on iPhone

Question

I've been suffering from severe performance problems rendering a regularly updated image to the iphone. After trying it on the iPad 3 today I found out that I was only getting 2fps. This was WAAAY too slow. As such I decided to profile and found that nearly all the time was spent converting the image into a 32-bit ARGB image (after the UIImage drawInRect). I'm seriously shocked at how awful the performance is given everyone says UIKit renders using OpenGLES.

So I converted the rendering code to GLES1 (I can't be bothered to set up a GLES2 renderer at the mo ;)). The performance has shot up. I'm now getting 20+fps. In fact the performance is so good I'm beginning to wonder whether I can perform full retina rendering!

Anyway I am creating the texture as follows:

glTexImage2D( GL_TEXTURE_2D, 0, GL_RGBA, width, height, 0, GL_RGBA, GL_UNSIGNED_SHORT_5_5_5_1, &colours.front() );

Unfortunately this reverses the component order. I have "fixed" it by reversing the bit order from:

val     = ((rgba.a >> 7) << 15) | ((rgba.b >> 3) << 10) | ((rgba.g >> 3) << 5) | ((rgba.r >> 3) << 0);

to:

val     = ((rgba.r >> 3) << 11) | ((rgba.g >> 3) << 6) | ((rgba.b >> 3) << 1) | ((rgba.a >> 7) << 0);

So this confirms that the component order is reversed over CGImage. However this code is used in multiple products so I need to come up with a way of loading the "component reversed" image.

As such I found the flag "GL_UNSIGNED_SHORT_1_5_5_5_REV" but I can't get it to work.

I've tried the following code:

glTexImage2D( GL_TEXTURE_2D, 0, GL_RGBA, width, height, 0, GL_RGBA, GL_UNSIGNED_SHORT_1_5_5_5_REV, &colours.front() );

and:

glTexImage2D( GL_TEXTURE_2D, 0, GL_BGRA, width, height, 0, GL_BGRA, GL_UNSIGNED_SHORT_1_5_5_5_REV, &colours.front() );

but both return me GL_INVALID_ENUM. So what am I doing wrong? Is it even possible to load the component reversed images?

Thanks in advance!

edit: In the interim I've introduced YET another pixel class and then added the following code:

inline uint32_t UpdateGLTexture( uint32_t texture, std::vector< R5G5B5A1 >& colours, unsigned int width, unsigned int height )
{
    std::vector< A1R5G5B5 > convertedColours( colours.size() );
    ColourSpaceConversion::ConvertFormat( convertedColours, colours );
    return UpdateGLTexture( texture, convertedColours, width, height );
}

So I now have correct rendering but I'm trying to avoid these kind of colour conversions. I may just create the source image in that format when using GL rendering but its annoying that I can't load the format directly :(

Answer 1

The reason GL_UNSIGNED_SHORT_1_5_5_5_REV doesn't work is because it isn't a texture format, though that would be super useful on iOS. The 1555 16b format is part of the GL_EXT_read_format_bgra extension (see the #ifdef block where it is defined), which defines this enum for glReadPixels only, not glTexImage2D unfortunately:

http://www.khronos.org/registry/gles/extensions/EXT/EXT_read_format_bgra.txt

This is annoying. iOS stores its 16b thumbnails in A1B5G5R5, and CGBitmapContext also supports A1B5G5R5 rendering, but OpenGL ES only supports R5G5B5A1 (5551) on iOS. AFAIK, there is no way to directly download the ALAsset thumbnails that use 16b 5551.

Answer 2

UIKit doesn't render using OpenGL ES, it merely caches the result in an OpenGL ES texture for compositing and transformations. The drawing of vectors is still CPU-bound, so quadrupling the number of pixels you have to rasterize to when stepping up to the Retina display will slow things down.

I'm not quite sure what you're trying to do, but it sounds like you want to upload BGRA data into your OpenGL ES texture. In that case, you'll want to do something like the following:

glGenTextures(1, &outputTexture);
glBindTexture(GL_TEXTURE_2D, outputTexture);

glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, (int)pixelSizeToUseForTexture.width, (int)pixelSizeToUseForTexture.height, 0, GL_BGRA, GL_UNSIGNED_BYTE, imageData);

Now, I'm doing a full 32-byte-per-pixel RGBA texture here, not the more compact one you attempt there, because I wanted that extra bit of color fidelity in the texture. I haven't tried, but I believe you can use the above with a more compact color format, as well.