[XMLLoader deferred loading]

Thanks for your answer!

That's correct - the vars object is for initial configuration upon instantiation, not for use after instantiation. To add listeners later, you'd use addEventListener() just like any other AS3 EventDispatcher. Since it would be impossible to reference functions inside your XML (after all, XML is just text/String, therefore cannot point to a function object), you cannot define onComplete there. See what I mean? It's simply impossible unless the scope is assumed (and locked into a particular object) which would be a bad architectural move.

I'm clearly understand impossibility of adding listeners via XML, but could be nice to mention in docs we should add them "classic way" since in this case we should add listeners not like usual while dealing with greensock classes.

 

However, we have ability to set loader's vars property - and it's really intuitive to set vars property to vars object, like ImageLoaderVars, including all necessary listeners and apply new vars on the fly (hey, we got new vars here and they contain listeners - let's add them if they already not set!), especially because we could wish to set some additional vars (like smoothing), not only listeners.

 

 

I'm not aware of any issues like that - I wonder if you forgot to clean up after yourself in a subloaded swf before unloading. For example, if your subloaded swf starts NetStreams, attaches listeners, etc., there's no way for LoaderMax/SWFLoader to know that - you must clean up after yourself (remove listeners, close NetStreams, etc.) in order to make stuff eligible for garbage collection. If you're still having trouble, please post a very simple FLA that we can publish to see the problem demonstrated clearly (no need to post your production files - just the simplest isolated example).

In my case, I loaded raw jpeg files only, using ImageLoader.

 

Before repeat file loading, I called ImageLoader.unload() on desired ImageLoader instance and called ImageLoader.load() on it afterwards. Memory increased slowly, not with BitmapData's definitely, more likely with something smaller.

I'll try to investigate further and make sure I'm not forgot anything.

[XMLLoader deferred loading]

If I have some ImageLoaders in the XML with load="false", XMLLoader creates instances for them and applies vars from XML without listeners, like onComplete.

If I apply vars with listeners later, after getting loaders via XMLLoader.getChildren(), listeners will not be set, so only way to listen complete event of the deferred loaders is adding an event listener directly, like:

 

var nextImageLoader:ImageLoader = _defferedLoaders[index];
nextImageLoader.addEventListener(LoaderEvent.COMPLETE, _onNextImageLoaded);
nextImageLoader.load();

It works for me, but it was not easy to came to this - I had to debug greensock sources to see what happens and why I can't use common vars syntax with deffered (load="false") loaders.

 

I tried both

nextImageLoader.vars.onComplete = _onNextImageLoaded;
nextImageLoader.load();

and

var imageLoaderVars:ImageLoaderVars = new ImageLoaderVars();
imageLoaderVars.onComplete(_onNextImageLoaded);
nextImageLoader.vars = imageLoaderVarsl;
nextImageLoader.load();

But it doesn't work for me - loading happens, but listeners are just ignored.

 

Also if I try to use deferred loaders and keep them for re-use, just unload()'ing content, memory consumption grows, like something still keeps internally and grow with every load() call.

[PropTween]

Thanks once again!

You're right! Just tested my swf with FlashDevelop profiler and there are no any issues with PropTween too, I'll report a bug to the TheMiner author.

[PropTween]

Thanks for your answer! Nice hint about looping the tween!

By "trashing memory constantly" I mean PropTween is growing constantly, up to very huge amount before collecting by GC. 5 minutes of waiting on the screen with 10 looped tweens can store more then 10 000 PropTween instances in the memory according to the profiler...

Here is a part of memory profiling data with 3 columns for the one frame render:

 

Added Removed Current

 

Array

0 0 71

Object

18 0 175

com.greensock.core::PropTween

37 0 11980

flash.events::Event

12 12 25

com.greensock::TweenLite

9 0 47

 

Current - is an amount of instances currently in the memory.

So, looks like PropTween is added on every frame, but not collected at all or collected too slow to keep it's count constant.

 

I tried to profile your speed test swf, and there is interesting thing - FAST tests have no this issue, usual tests - have it.

Please, look at the TheMiner memory profiler via PreloadSWF (http://www.sociodox.com/theminer/support.html) on your speed test to see what I see...

Maybe it's a bug in the profiler and it just don't "see" how PropTween instances are collected?

 

Thanks!

[PropTween]

Hi! With help of profiler, I'm noticed PropTween is trashing memory constantly if I have some looped TweenLites on scene. This is really annoying on mobile devices because it forces garbage to keep growing and GC to work what leads to the FPS drops =(

 

I should mention how Animator lopped them:

 

_in();
function _in():void
{
TweenLite.to(this, spd_02, {scaleX:1.2, scaleY:0.8, ease:Sine.easeInOut, onComplete: _out});
}

function _out():void
{
TweenLite.to(this, spd_02, {scaleX:1.0, scaleY:1.0, ease:Sine.easeInOut, onComplete: _in});
}

 

I know there are repeats and yoyo available in TweenMax, but looks like PropTween still trashes the memory even with yoyo and repeats=-1 =(

 

Please, let me know if there is some kind of workaround exists for this case, thanks!