dispose causes terrible performance problems with tween

[Thorjelly]

Hey everyone,

 

I have modules which are loaded in using the SWFLoader, and then faded onto the stage using TweenLite. This was working great. However, I am finding that whenever I dispose of the contents of the SWFLoader, it causes the tween to lag horribly, reducing very smooth fading to 3-5 fps. It works perfectly if I do not call dispose on the object. I am calling dispose before the tween is initialized. I would assume that if Dispose takes a while to complete, it should just cause the program to delay until it is done and then add the module and tween it. But this is not what is happening.

 

I tried, instead of adding the displays of the modules right after the dispose command, adding an LoaderEvent.UNLOAD listener, and updating the displays after that gets fired. However, LoaderEvent.UNLOAD does not seem to fire at all, even using the command loader.empty(true, true) on a LoaderMax object which contains all the loaders for the modules that need to be loaded in at once. It should be noted, all the graphics are loading fine so it shouldn't be a problem with the content being flushed... in fact, even calling loader.dispose(false) in the individual SWFLoaders causes it to lag like this.

 

Here is some code:

 

	_loadController = new LoaderMax( { onProgress: onLoadControllerProgress,
										   onComplete: onLoadControllerComplete,
										   maxConnections: 4 } );

	// this actually starts the loading process; moduleDisplay dispatches
	// LoaderEvent.INIT (for lack of a better event name) after the loader
	// has been created, but the loader is not yet started.
	private function onModuleLoadInit(event:LoaderEvent):void
	{
		_loadController.append(event.target as ModuleLoader);
		_loadController.load();
	}

	// If the download would take more than 2 seconds, show the loading
	// animation
	private function onLoadControllerProgress(event:LoaderEvent):void
	{
		var secondsLeft:Number = ((event.target.bytesTotal - event.target.bytesLoaded) / 1024) / WILDLoader.BANDWIDTH;

		if (secondsLeft > 2 && this.enabled)
			showPreloader();
	}

	// when ALL loading is complete, clean up loader and update display
	private function onLoadControllerComplete(event:LoaderEvent):void
	{
		_loadController.empty(true, true);
		hidePreloader();
		updateDisplays();
	}

 

Also, if I update the displays this way, it doesn't work at all because LoaderEvent.UNLOAD apparently fails to fire (the event listener is actually added in the constructor):

 

	_loadController = new LoaderMax( { onProgress: onLoadControllerProgress,
										   onComplete: onLoadControllerComplete,
										   onUnload: onLoadControllerUnload,
										   maxConnections: 4 } );

	// this actually starts the loading process; moduleDisplay dispatches
	// LoaderEvent.INIT (for lack of a better event name) after the loader
	// has been created, but the loader is not yet started.
	private function onModuleLoadInit(event:LoaderEvent):void
	{
		_loadController.append(event.target as ModuleLoader);
		_loadController.load();
	}

	// If the download would take more than 2 seconds, show the loading
	// animation
	private function onLoadControllerProgress(event:LoaderEvent):void
	{
		var secondsLeft:Number = ((event.target.bytesTotal - event.target.bytesLoaded) / 1024) / WILDLoader.BANDWIDTH;

		if (secondsLeft > 2 && this.enabled)
			showPreloader();
	}

	// when ALL loading is complete, clean up loader and update display
	private function onLoadControllerComplete(event:LoaderEvent):void
	{
		_loadController.empty(true, true);
	}

	// when the loader controller is unloaded, update displays and remove
	// preloader
	private function onLoadControllerUnload(event:LoaderEvent):void
	{
		hidePreloader();
		updateDisplays();
	}

 

Does anyone know what could cause this sort of problem?

 

Thanks

[GreenSock]

I couldn't seem to reproduce any of the problems you mentioned. I tried code almost exactly like what you posted and it worked great. However, I'm not sure what a ModuleLoader is - did you create that yourself by extending SWFLoader or LoaderItem or something? I wonder if the problem is in your ModuleLoader class. If you're still having trouble, please post a very simplified FLA that clearly demonstrates the issue with as little code as possible. Then we can download it and publish it on our end to see what's going on.

[Thorjelly]

Hey,

 

Thanks for the reply. My ModuleLoader code is just this:

 

package test 
{
import com.greensock.loading.SWFLoader;
import flash.system.ApplicationDomain;
import flash.system.LoaderContext;

public class ModuleLoader extends SWFLoader
{
	private var _applicationDomain:ApplicationDomain;

	public function ModuleLoader(moduleUrl:String)
	{
		_applicationDomain = new ApplicationDomain(null);
		super(moduleUrl, { context: new LoaderContext(false, _applicationDomain) } );
	}

	public function get applicationDomain():ApplicationDomain { return _applicationDomain; }
}
}

 

That is, it just extends SWFLoader for a very easy to access applicationDomain property, so far.

 

Anyway I tried to reproduce the problem in as little code as possible. I was not able to reproduce it however. Oddly, the problem is that I cannot reproduce it ever being fast to begin with -- in my test .fla it is slow no matter if it disposes or not. I'll try to see if I can reproduce it exactly and get back to you.

 

Thanks

[jvalenzu]

Any update on this? I'm explicitly calling unload/dispose on swfLoaders I'm done with and the regularly get drops down to 2fps.

[GreenSock]

Any update on this? I'm explicitly calling unload/dispose on swfLoaders I'm done with and the regularly get drops down to 2fps.

Have you tried NOT unloading/disposing to see if your frame rate improves? I'm just curious if you're saying the problem is specifically caused by unload() or dispose(). I'm not aware of any issues with LoaderMax causing a massive slowdown like that.

[jvalenzu]

Yeah - removing the calls to unload/dispose solves the problem. I thought for a bit it might be the explicit garbage collection but setting DisplayObjectLoader.defaultAutoForceGC to false doesn't seem to change anything.

 

This is with a LoaderMax instance with ~197 swfLoaders with completed status. Anything else I should try?

[GreenSock]

Does it happen on Windows and Mac? Almost sounds like a problem with Flash itself, but it's very difficult to say without seeing your files and being able to publish and test on our end. Have you tried different, very generic swf files just to see if maybe some of the ones you're loading now are causing the issue due to something inside them? [scratches head]

[jvalenzu]

Well, the problem doesn't seem to be restricted to unloading any particular file. It's not really possible to just drop in a generic replacement, but I'll see if I can get simple test case up. Is there something specific I should be looking for in our assets that might cause a problem?

 

I'm disinclined to this it's a Flash problem - we have non-LoaderMax loaders present in the application as well and they don't seem to exhibit the problem - but I can't rule it out. I'll see if I can narrow it down in any case.

[GreenSock]

I'm disinclined to this it's a Flash problem - we have non-LoaderMax loaders present in the application as well and they don't seem to exhibit the problem - but I can't rule it out.

Well, LoaderMax simply uses standard Adobe Loaders internally, so it's not like there's any voodoo magic in there

 

What version of LoaderMax are you using? I wonder if you're using a stale version.

 

Also, when you did a test without LoaderMax, did you call unloadAndStop() on all your Loaders? Did you listen for uncaughtErrorEvents?

[jvalenzu]

We're running 1.895 here.

 

Just to clarify, we have some loaders using LoaderMax and some not using LoaderMax, but they both run simultaneously. It's not possible at the moment to just flip a switch so that we're entirely using LoaderMax or not-LoaderMax, so I can't say with certainty that it's the problem - it's entirely possible the error is in the way we're using it.

 

I don't think it's the unloadAndStop: I made a subclass of SWFLoader and removed the property on the loader before invoking it. This should rule that out, right?

 

   public class IgSWFLoader extends SWFLoader
   {
       // ...
       override public function unload():void
       {
           if (_loader && _loader.hasOwnProperty("unloadAndStop"))
               delete _loader["unloadAndStop"];
           super.unload();
       }
   }

[GreenSock]

I don't think it's the unloadAndStop: I made a subclass of SWFLoader and removed the property on the loader before invoking it. This should rule that out, right?

No, that wouldn't work (or shouldn't work at least). Loader isn't a dynamic class. You can't just delete a method like that.

 

If you wanted to avoid that call, you'd need to dig into the DisplayObjectLoader class and comment out the unloadAndStop() call there.

 

I would DEFINITELY recommend updating to the latest version of LoaderMax. You've got a stale one for sure. http://www.greensock.com/loadermax/

[jvalenzu]

Thanks for the response - I guess I'd assumed that a class that extends a dynamic class must be dynamic. Obviously I'm a flash neophyte.

 

After some slightly more rigorous testing I think the problem I'm seeing is attributable to the gc being invoked during unload. Setting DisplayObjectLoader.defaultAutoForceGC, explicitly invoking unloadAndStop(false) for _loader, and some reordering how we invoke the LoaderMax calls (I don't think these are relevant, but can't rule them out) seem to fix us up. I'll probably hold off upgrading unless it's really necessary, but if I do I'll report back any differences.

 

Thanks again for the help!