IPhone OS: strategies for working with high image density
I have a project that is about to approach bending this summer that will potentially involve an extremely large amount of image data to display. We're talking hundreds of 640x480-ish images in a given application session (scaled to a lower resolution when displayed) and several very large (1280x1024 or higher) images at a time.
I did some preliminary work already and I found that a typical 640x480ish image is just a shade under 1MB in memory when placed in a UIImageView and displayed ... but very large images can be a whopping 5+ MB in some cases.
This project is actually targeting the iPad, which in my experience in Tools seems to cover about 80-100MB of addressable physical memory.
Specifically, I need to start thinking about how to move huge amounts of image data between virtual and physical memory while keeping the application fluid and responsive, which will be high visibility.
I'm probably at the top ends of an intermediate level in Objective-C ... so I'm looking for some solid articles and advice on the following:
1) Responsibly managing UIImage and UIImageView in the name of conserving physical memory 2) Benefits of using CGImage over UIImage, especially for huge images, and if there is any performance improvement 3) Everything related to paging memory, especially when it comes to images
I will be an epilogue by saying that the numbers that I have higher can be around 10 or 15%. Images may or may not end up in the actual application rather than being downloaded from an external server.
a source to share
CATiledLayer is probably the way to go. The only reason to create a UIImageView for each image is if you want interactivity that is driven for you. CATiledLayer will allow you to load and draw images asynchronously from background threads as needed. Just use a CGImage as this is what you draw on the layer anyway.
You will probably want to implement your own streaming image cache so that you can put a limit on the number of images stored in memory and start loading images when you predict that they will be needed soon. If the download is not complete when a draw request comes in, you can block the downstream thread.
a source to share
Images usually have a lot of repetitive data and are good compression targets. it depends on what format you are using for your images and if it is built into compression. My first thought is to stick with the png format because it is native to the iPhone and uses a compression archive for most of your images in some way. Something like .zip or .rar.
if you can identify batches of images that the user may encounter, you can unlock them and present them to the user. It may be useful to use the "thumbnail" subelement archive.
I'm not sure what all this compression and decompression will do with your response time, but its an idea to reduce your memory footprint.
a source to share
This is a pretty big question, so I'll point you to a project that is an open source view. Maybe you can reuse this project in bulk by adding your server as data source (if it's lng / lat based on what might make sense), or you can take some design patterns and implement your requirements directly.
http://code.google.com/p/route-me/source/browse/trunk#trunk/MapView/Map
The fact that your images are 1mb or 5mb is not a problem as you only have to display 1 or 4 images at a time. An asynchronous cache loader is then executed, which populates and grows your image cache based on what the user may be looking at next. Then, when the user interacts, grab the image from the cache (or a counter in the cache miss) and add it to the CALayer and put it in the CALayer hierarchy.
There are many questions about performance / usage. I would like to connect with someone in the project above or just follow their example. Based on what I know about the project, this means one UIView for the parent container that goes through the events and using CALayers for the entire tile. CGImageRefs are used in CALayers, so stick with them.
Hope it helps.
a source to share