re: memory management issue

[Robert Friston]

Hi All,

I am building an App that is heavy on animation and sound samples etc, and I am struggling to get enough free memory to get the effects that the client is looking for.

There is no real problem on the iPad 2, but 1 out of every 3 run through's on the iPad 1 crashes at certain points where animations are loaded up.

I have checked all the obvious stuff, no memory leaks, no needles loading of images using imageNamed, no holding onto cached table cells, etc, etc...

It really is a simple case of not enough memory, so I am trying to find ways of forcing stuff out-of-memory in advance of the problem areas in the hope that this could fix the issue. I have seen references to sharedImageCache and the like but nothing that actually works in the code without errors.

- (void)applicationDidReceiveMemoryWarning:(UIApplication *)application {     [[ImageCache sharedImageCache] removeAllImagesInMemory]; }

any ideas anyone?? Is there a way to force IOS to just effectively dump all images, sound files and the like from memory on demand?

Cheers

Bob

[Chris Ross]

Initial thought: are you using imageNamed: ?

If memory is tight and you are loading a lot of images with imageNamed: you could balloon memory use.

I recommend using UIImage alloc+init and release the images when done.

imageNamed: does lots of weird behind the scenes caching type things that is nasty for one shot images etc.

Chris

> --
> You received this message because you are subscribed to the Google Groups "Brighton iPhone Creators" group.
> To post to this group, send email to brighton-iph...@googlegroups.com.
> To unsubscribe from this group, send email to brighton-iphone-cr...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/brighton-iphone-creators?hl=en.

[Robert Friston]

Hi Chris

Thanks for your quick response. Yes, I cleared out all of those.

Also I noticed very strange disproportionate memory ballooning that happens if the image size is physically larger than 1024x768 (even if a low resolution image like a GIF of JPG).

Bob

[Frank Barnhouse]

Ah, I was wondering if that might be the case...

PNGs can be mapped directly into memory (meaning the size of he PNG is
how roughly how much memory they occupy). Compressed image files like
GIF and JPEG can't be mapped directly and can consume inordinate
amounts of memory.

I ran into this issue whilst developing a book app on the iPad. We
converted our JPEGs to PNG and gained a lot more memory headroom.

-Frank

[Paul Ledger]

Hi Bob

Not sure what you need but have you looked into using CATiledLayer? There is a sample project on the Apple dev site that shows how to render large images using this. I've just completed an app that is rendering an image taht is 29,528 x 2,919 and 14.7Mb in size

Paul

[Robert Friston]

Hi Paul, Frank, Chris

Thanks for the suggestions. My problem is that I am loading largish images into a table view (pages of a book basically). Then for each page other visually content appears and is animated. Each page is about 500kb on average (I've tried both PNG and JPG formats), but then there is a need for some fairly large animations to happen on cell load.

Looking at Instruments what seems to be happening is that sometimes the IOS is not getting a chance to self-clear it's cache of tableview cells in time - before it crashes from running out of memory.

Sounds crazy I know - but that is what seems to be happening.

It seems odd that we have the didRecieveMemoryWarning delegate - but then no system calls that allow the coder to dump cached memory in the TableView object... I am pretty certain this is the issue, as sometimes it works fine when it clears the cache automatically just-in-time and then you can see all the freed up memory appear again in Instruments, and the App works perfectly without crashing.

Arhhh!!

Bob

[Adam Martin]

I've been working on an app recently that is very greedy for RAM, and noticed:

1. If you use up all RAM on the device "quickly", Apple decides it's
your fault, and kills the app
2. If you use up the same amount of RAM "slowly", Apple decides it's
the other mem-resident apps' fault, and kills them

So, for instance, if you can take 5-10 seconds to use up RAM, instead
of 1-3 seconds, *yours* won't be the app that's killed.

Looking at your notes below, I wonder if Apple's own app-level /
library code may have some time-based heuristics on how aggressively
it de-caches?

However ... Apple is pretty clear that TableView is explicitly NOT for
displaying large amounts of information - unless you're prepared to
heavily customize it. In iPhone OS 2.x days, Apple practically seemed
to be saying:

"Don't use TableView ... for anything. We only provided it as a
reference example of how you could - theoretically - do small tables
of text-only info. We'll (maybe) provide a more sane/performant
alternative in a future iOS release".

At the time, I got the impression they were suprised how much people
were using TV / UITVC. 3.x improved things a lot - I suspect in
reaction to how many people were using them all the time - but I'd
still be wary of them. I've seen a few open-source TableView
alternatives that attempt to improve the mem performance and rendering
performance in obvious ways (I'd recommend goolging for them and
trying some of those).

...or else: re-consider your app design, and ask how it can be
achieved without using tableviews. Obviously, I don't know your app,
but "pages of a book" sounds like an odd thing to be putting into a
tableview?

[Adam Martin]

I've never managed to get CATiledLayer to work well. Recently we've
done a project in OpenGL partly to avoid CATiledLayer.

Since CATL came up on Thursday, I've been wondering about that, and
just did some research today. Turns out CATiledLayer changed in iOS 4
- personally, I'd only tried it with 3.x - and it looks like it's
better now.

c.f. this CIMGF post from earlier this year:
http://www.cimgf.com/2011/03/01/subduing-catiledlayer/

Although ... looking at CIMGF description ... it seems that CATL is
still avoiding the issues of tile-caching, and leaving it up to you?
In which case, I don't think it would have saved us from any of the
difficult bits of what we were doing (i.e. controlling which textures
got cached at which level - RAM, VRAM, etc). IME it's the
tile-management and tile-caching that is the bulk of the code, not the
"deciding which part of a large image to render from tiles".

So ... I'd be really interested in hearing more about youre
experiences with it, Paul - maybe a talk in 4 weeks time? :) (hint,
hint)

Adam