The 256MB Device Difference Which Isn't Documented
The 7.1.1 SDK update allows us to support and detect devices with only 256MB and there are a few noted points of things to avoid on the 256-MB devices. Recently I've discovered another one.
32Bit image support!
256-MB images only support displaying images at 16 Bits Per Pixel.
For most cases this isn't a problem, but if you're using gradients it may be.
Let me demonstrate with a simple app.
The app just shows an image with a gradient (from red to cyan) and an indication of if we're running in the regular emulator (with 512MB of memory) or the version with 256MB.
Here's what it looks like by default on the 512-MB emulator.
You'll notice the banding of the color in the gradient.
The standard way we'd adjust the app to cope with this would be to configure the app to use 32bits per pixel-which is enough to show the full range of colors in the gradient.
There. Much better. No banding.
But what if we flip over to the other emulator the problem returns.
Oh no. The banding is back. And yes, we have still configured to use 32 BitsPerPixel
But, you may be thinking, perhaps this only affects the emulator.
No. I've tested this on a Nokia Lumia 610 (which is a 256MB device) and the same thing happens there.
So what can we do?
We can dither the image.
Voila. A lot less banding.
Now we can use a gradient image in an app on a 256MB device without banding.
The dithering in the above example was done with the tool from http://adtsai.blogspot.co.uk/2011/03/high-quality-dithering-for-windows.html
On the plus side we can use this same image on 512MB devices without the need for the memory overhead of using 32BPP.
On the negative side the dithered image is larger though.
Presumably, this lack of support for a higher number of bits per pixel, has been done to reduce the amount of memory needed to display graphics and therefore reduce the total memory used by the app.
If you're going to use gradients in your apps this is an important thing to be aware of.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)