One of the most problematic constraints when developing applications for mobile or Set Top Box is video memory (AKA VRAM). You often will not have control over how much video memory is allocated to your application, or what the fallback behaviour is when your application uses too much.
This can be a pain, especially when you wish to create some off-screen surfaces for caching or compositing to improve performance.
If your application runs too slowly, that’s an ISSUE; if your application crashes due to excessive memory usage, that’s a PROBLEM.
I recently built a feature into an application which required a bunch of external images to be loaded into a Set Top Box device for in-process caching. Since all Bitmap surfaces are allocated on the platform as ARGB, but the images were monochrome, I could store the images efficiently AND make them available for hardware-accelerated compositing by storing just the single monochrome channel of each image in a separate channel of an in-process cache Bitmap surface.
You can see in the attached image what a a mish-mash of logos is created. For debugging purposes, you can also see the same surface viewed with each other channel turned off. When a logo is requested, a dictionary finds the relevant Bitmap slot it exists in (given by a Rectangle and BitmapDataChannel number). When a new image is loaded, its single channel is copied into the next available slot in the cache, in FIFO fashion.
The alpha channel of the cache surface wasn’t used, due to the pre-multiplication problems you’ll get – though this can be worked around if you can ensure there are no zero-alpha pixels. The result is an in-process cache requiring no image decoding to composite images, storing 3 times as many images as a regular Bitmap FIFO. #WIN