jefbut

I am using latest spine-csharp and spine-xna with Xamarin Studio developing iOS apps. I tried updating to latest source in the hope it would fix my problem but it didn't :-(

I am doing an interactive book. Each page is set up with its own background image (drawn just using SpriteBatch) and a set of spine animations. I have a ContentManager, SkeletonRender, Skeleton and Atlas on each page. I should only have a couple of pages in memory at a time, so I want to make sure I free any pages not currently in use.

If I take two pages and scroll back and forth between them, I get a memory warning after say 30 transistions back and forth and program eventually crashes. If I remove all the Spine stuff, I can transition back and forth as long as I want so I am happy I am unloading my rather large background images correctly.

As soon as I have the following in my LoadContent:
_atlas = new Atlas("Content/File.Atlas", new XNATextureLoader(GraphicDevice));

And this in my Unload:
_atlas.Dispose;
_atlas = null;

I am having a problem. I go back to only being able to do a limited number of transitions before crashing.

That does make it seem like a Spine issue doesn't it? I don't like raising issue of memory leaks in case its something in my code but I have spent hours going through my code, its late and my brain is going to mush. As far as I can see it's something in Spine but I haven't been able to spend any time going through the source.

Any suggestions?

BTW am loving Spine. Got some awesome animations for my book which I will load into Showcase forum at some stage but this issue is holding me up.
jefbut
  • 記事: 13

Nate

I assume you have atlas.Dispose() with parenthesis? The XnaTextureLoader should call Unload on the Texture2D. Can you verify this is happening?
アバター
Nate

Nate
  • 記事: 11544

jefbut

Yes parenthesis are there. I told you it was late :-)

So tracing through the code, the atlas.Dispose() performs a loop calling textureLoader.Unload(pages[I].renderObject);

The Unload is doing a ((Texture2D)texture).Dispose();
jefbut
  • 記事: 13

Nate

Ok, that is how it should be. Atlas doesn't do much else, it is just some objects. Are you sure you don't keep any references to it? Maybe the GC hasn't kicked in? Then again if we aren't leaking textures, I doubt the atlas has enough data to exhaust memory even if it were leaking. Is it possible to determine where the memory has gone? I'll try to look at it today.
アバター
Nate

Nate
  • 記事: 11544

jefbut

When I run Instruments and follow memory usage in Allocations, I see that when I transition screens there is about ten seconds where the memory usage goes up and then comes down. If I add a GC.Collect() after I call RemoveScreen() it peaks and drops pretty much immediately. So having the GC.Collect in speeds up my debugging. What I notice is that every so often it gets a double peak of memory usage. So instead of going from approximately 7MB to 12MB to 7MB. it will go from 7MBto 12MB to 16MB then back to 7MB.Almost like it is loading two lots of screens but I have no idea why that is happening. I have added Debug.WriteLines() to ensure that it activates and unloads transitioning screens in the correct sequence and it does.

Also monitoring the VM Tracker to show total memory in use, etc. When I don't create the atlas, the resident memory and dirty size will go up and down. It does seem to trend upwards but slowly. Once I start creating the atlas, it just keeps growing, it only very occasionally seems to shrink. It keeps growing and eventually crashes.
jefbut
  • 記事: 13

jefbut

It turns out that I can make the app crash without creating the atlas. It takes a LOT more transitions but does eventually happen.
jefbut
  • 記事: 13

jefbut

Found it!

In LoadTexture in Util.cs you need to have:

device.SetRenderTarget(null);
spriteBatch.Dispose(); // need to add
file.Dispose(); // need to add

There are still some small leaks in there somewhere but nothing I am going to worry about. Its only bytes now instead of MB. This was the biggie.
jefbut
  • 記事: 13

Nate

Ah, that makes sense. Sorry I didn't think to look there, that code was contributed. Committed!
アバター
Nate

Nate
  • 記事: 11544


Return to Runtimes