I fear this is evil code:
CGRect iRect = CGRectMake(0.0f, 0.0f, 320.0f, 400.0f);
UIImageView *imgView = [[UIImageView alloc] initWithFrame:iRect];
imgView.animationImages = [NSArray arrayWithObjects:
[UIImage imageNamed:@"b0001.png"],
[UIImage imageNamed:@"b0002.png"],
// 150 more
[UIImage imageNamed:@"b0152.png"],
nil];
I slightly remember that imageNamed: is evil. If I do it this way, and I have to provide UIImage objects, then those UIImage objects immediately load those image files into memory, right? And, besides that, all those 152 chunky UIImage objects take a big break in memory because they are autoreleased, isn't it?
So in conclusion, using this technique sucks. Does it? I don't know. On my age old first gen iPod touch this seems to run with no lag at 25 fps. Very smooth and nice. The only thing I fear about is that some other devices may think different about this. Although I have the weakest programmable ipod touch available.
Anyways, does anyone see any improvement possibility there? Or should I not use that and use setImage: of UIImageView in an own algorithm which would load and set those images with delayed selectors using that chunky imageWithContentsOfFile thing (may be named different), with no autorelease? Maybe some clever guy wrote a little lib for high performance thumb vids that consist of image sequences?
(no, video is no an option on the iphone; the apple frameworks for this just supports fullscreen, and I don't know of anything else that would do it)