On May 6, 2010, at 11:19 AM, Philip Mobley wrote: >> For images I would use a cost estimate of width * height * 4 (this is >> typically what the memory cost to decompress and display an optimized PNG). > > Yes, this is what I was planning for image memory estimates. Should I also > add in something for a image header especially if I use a lot of tiny images? > I was thinking something like +64 to +128 bytes to the estimate. Also I > think I will be storing the UIImage object in resource manager but only > exposing the CGImageRef as read-only data. I would assume that most of the > header properties would be mapped from the CGImageRef to the UIImage.
I wouldn't bother to be honest. Small allocations tend to not be given back to the system when you free them (because malloc() uses a sub-allocator for small allocations). >> For audio this is more difficult as it is unlikely that the entire file will >> be loaded into memory, or even that a significant amount of it will be >> loaded into memory unless it is playing (in which case you do not want to >> unload it). > > At this point, I don't even know which sound API am going to use. I would probably survey your sounds then. Most audio will likely be streamed into memory (certainly anything over a few seconds). A reasonable estimate might be to determine how much memory is required for 1 second of the audio to play (sample rate * number of channels * bytes per channel). This is likely to cause you to favor discarding images over audio, but in terms of memory impact on the system this is likely to be the correct choice. -- David Duncan Apple DTS Animation and Printing _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
