Error on dispose of loader

[prestont]

So I am using SWF loader to download a large number of individual assets as needed.

Since i reuse them a lot (in a game) , after load I simply read out the class and store it in my own lookup table.

 

public function gameSwfLoadComplete(e:LoaderEvent):void {

var swfl:SWFLoader = e.target as SWFLoader;

ImageManager.instance.loadDone(swfl.name,swfl.getClass(swfl.name));

}

 

I have been using this code for a few weeks but starting to see some performance issues. I realized i was leaving around the SWFLoader and DisplayObject so I added a third line to the above function:

swfl.dispose(true)

 

However, when I do that I suddenly start getting a lot of this following error:

Error #2044: Unhandled IOErrorEvent:. text=Error #2035: URL Not Found.

 

As far as I can tell, it does recover and the art is downloaded but I don't know why I am getting this and what might be happening.

 

And to clarify, I create a new SWFLoader each time:

 

var swfl:SWFLoader = new SWFLoader(n,{name:rname,autoPlay:false,onFail:gameSwfErrorHandler,onComplete:gameSwfLoadComplete});

_gameLoader.append(swfl);

_gameLoader.load();

 

 

Thanks,

Preston

[GreenSock]

Wouldn't you want to dispose(false) rather than dispose(true)? Remember, if you pass "true" to dispose(), it also unloads the content but you said you're trying to use that later. dispose(false) would simply get rid of the loader itself and make it eligible for gc.

[prestont]

I am getting the class already in line with:

 

swfl.getClass(swfl.name)

 

and storing that myself so I don't see why I would need another reference to it. I would rather not keep the extra object around unless it is necessary.

As far as I know there is no way for one object to force GC on a pointer that is still referenced in flash.

 

dispose(false) does seem to remove the error message but keeps more memory for something I will never access.

[GreenSock]

When you dispose(true) or unload() a loader [as long as you published to FP10 or later], then the Loader's unloadAndStop() method is called which does a bunch of stuff under the hood to dump the original data from the swf. This is likely the cause of your problems. And this has nothing to do with LoaderMax - it's a method from Adobe's Loader.

 

Your code was basically saying "give me that class from the swf...and destroy everthing that was in that swf (which includes this class I asked you for)". See the problem?

 

And to be clear, I wasn't advocating that you keep an extra object around - I'm not quite sure where the miscommunication happened.

 

Does this clear things up for you?

[prestont]

Thanks for the explanation. All I meant by the extra class was my understanding is that unless I did dispose(true) the ContentDisplay object, which I wasn't using, stuck around which seems to account for about 15% of my active memory and that was why I was using true instead of calling it with false.

 

I figured the call was safe since I had a reference to the class. In fact, it actually appears to work fine and the user doesn't see anything unless you have the debugged version of flash player installed so I guess I can go with it and see what happens.

 

Thanks again,

Preston

[BGoulette]

I'm experiencing similar issues, and after reading this thread, I still have a question:

 

I'm doing the same thing, storing LoaderMax-loaded content in separate variables; for example: mySwf=MovieClip(LoaderMax.getContent("swfurl")).

 

After that, I'm running loader.empty(true, true) to try to keep as few items around as necessary.

 

I guess what I'm asking is: Am I keeping double the items in memory if I only call loader.empty(true, true) versus loader.empty(true, false)? Or, because I'm storing a reference to the items elsewhere, I wouldn't be bloating things by not unloading the loader's contents? (I'm confusing myself with my tortured sentence structure -- sorry!)

 

I only see the error when I'm simulating a download from within Flash (haven't moved to trying it on a server yet). And even though the error shows up in the output window, it doesn't seem to affect the actual functionality of my project.

 

Just hoping for some clarification -- I'll admit I'm woefully unenlightened when it comes to garbage collection! Thanks!

[GreenSock]

Think of the SWFLoader instance itself as an object, and the content that it loads as a completely separate and distinct object. When you dispose the loader instance (like dispose(false)) it only kills the SWFLoader but NOT the content it loaded (which you might be using elsewhere in your app). If you're done with the loader instance and you've already gotten your content, you can dispose of the SWFLoader. Just keep in mind that after you dispose of it, you cannot get its content with LoaderMax.getContent("myLoaderName"). All the internal references that LoaderMax used related to that subloaded content are killed, but the actual content isn't. See the difference?

 

If, however, you dispose of both the SWFLoader and its content (like if you dispose(true)), then the loader instance AND the content are both dumped. If you're done using the loader and the content, go ahead and do that. But typically people don't want to dump the content (after all, they subloaded it for a reason).

 

So in your case, it sounds like calling empty(true, false) would be fine (assuming you do that after you got whatever content you need). That will just dump all the loaders themselves, but it won't mess with the content.

 

Make sense?

[BGoulette]

Jack,

 

Yes, that makes sense, and shortly after posting, I messed around with my code some more -- well just setting loader.empty(true, false) -- before realizing that loader.empty() was the same thing (default values). So I changed it to that, and I didn't see any change in performance or weird issues with the bandwidth profiler, so I'm good to go for now!

 

As always, thanks very much!