0

I am using Cocos2d 2.0 and XCode 4.5.2 and I do wonder how I can detect which spritesheets/images are still on memory at a specific time.

Example: In Scene I load images.pvr.ccz spritesheet, then I call replaceScene loading Scene2. Whilst Scene2 is running I want to see if images.pvr.ccz is still in memory as the resident memory increases at each scene.

Should I use some instrument tool or shall I instead add some breakpoint in the texture cache related classes?

I do add the images to the frameCache as following:

 [[CCSpriteFrameCache sharedSpriteFrameCache] addSpriteFramesWithFile:@"images.plist"];
        batchNode = [CCSpriteBatchNode batchNodeWithFile:@"images.pvr.ccz"];
        [self addChild:batchNode];

Additional details - not needed

I have the following beheaviour: every time I replace a scene the memory increases by the "x" MB that could correspond to the spritesheet size.

I added those calls at the init method of each scene, however the memory still increases:

    [CCAnimationCache purgeSharedAnimationCache];
    [CCShaderCache purgeSharedShaderCache];
    [[CCSpriteFrameCache sharedSpriteFrameCache] removeUnusedSpriteFrames];
Community
  • 1
  • 1
mm24
  • 9,280
  • 12
  • 75
  • 170

1 Answers1

2
[[CCTextureCache sharedTextureCache] dumpCachedTextureInfo];

Use this call to see what textures are load into the memory at the moment. Also if you want to remove unused textures, use 

[[CCTextureCache sharedTextureCache] removeUnusedTextures];
Morion
  • 10,495
  • 1
  • 24
  • 33
  • I really don't understand. I added the calls and I get 1 texture for 8MB of usage but, looking at the resident memory info, I get an increase of 8MB each time I load the scene (hence the texture gets somehow re-loaded each time). I am lost.. :( – mm24 Sep 06 '13 at 11:04
  • The texture is loaded into memory only once. Are you sure that your memory is leaked because of textures? No large amounts of data, sounds or something else loaded? – Morion Sep 06 '13 at 11:08
  • I added a CCLOG to print the textKey on the dumbInfo and the spritesheet of the previous scene gets cached. I guess that this should explain part of the memory increase. However I have no idea on how to force its removal. – mm24 Sep 06 '13 at 12:51
  • make sure that there all objects from your previous scene are destroyed after you replacing scene. – Morion Sep 06 '13 at 12:56
  • I added "[[CCTextureCache sharedTextureCache] removeAllTextures];" and the texture sheet get removed, however the memory stays the same. I guess that need to investigate the rest as u suggested in the second comment. – mm24 Sep 06 '13 at 12:57
  • What is the standard way to make sure that all objects are destroyed? Should I look for the object name in the Allocation tool and if I don't see the name then means that has been destroyed? The issue is that I am using ARC and I got no dealloc method where I can play with this. – mm24 Sep 06 '13 at 12:58
  • I checked with Allocation tool for the name of classes of the previous scenes but they do not show. Mystery :) – mm24 Sep 06 '13 at 13:05
  • @Marion (1/2)I have used your approach plus a dump of the amount of resident memory. Initially I was getting confused as I was calling the resident memory dump info function in the init method of the new scene. This was causing a concurrency problem as the 2 scene are alive at the same time and hence the assets are stil in memory so the memory was "not" decreasing. Adding a callback with a 0.1 seconds delay solved the issue. However there are cases (in scenes with no images the removeAllTexture does not work straight away and I do still get the memory loaded after 0.1seconds and even 1 second) – mm24 Sep 19 '13 at 07:48
  • (2/2) it just seem not to trigger the texture removal if there is no other texture being loaded in the init method. I find this weird as it should behave the same way (the texture removal is called as first thing in both cases). I have put this in this question http://stackoverflow.com/questions/18706146/cocos2d-removespriteframes-and-removealltextures-do-not-work-straight-away/18706277?noredirect=1#comment27591645_18706277 however I accepted the answer as the answer makes sense for most of the cases (this is a specific case and would be nice if anyone can solve it, if so please add as answer) – mm24 Sep 19 '13 at 07:50