Jump to content
GreenSock

Search In
  • More options...
Find results that contain...
Find results in...
Amnesicat

Loader/Tween Disposal

Recommended Posts

Hello,

 

I'm having a bit of trouble with some memory leaks that seem to happen when disposing a Videoloader that has a tween on it's content.

 

I've attached a very simple FLA example below that loads a swf containing a Videoloader which loads a single video. Pressing unload calls a dispose function inside the swf which should dispose of the video and tween. Repeatively pressing unload/load quickly increases memory usage, and according to the Flash Builder profiler there are increasing numbers of Videoloader instances being retained with no release.

 

Although the strange thing is that if there is no tween on the video it works fine, no increase of memory or Videoloader instances at all.

 

So, am I missing something? Why is this happening and how can I rectify it?. Any advice would be greatly appreciated.

 

FLA Example: http://snk.to/f-cdh8238p

 

Thanks a lot,

Alan

Link to comment
Share on other sites

Carl and I both tested the FLA and pressed load and unload many, many times very quickly and couldn't get the memory usage to keep rising (it'd hit somewhere around 30 and then go back down). I'm not quite sure what to say other than hopefully it's good news that we can't replicate the problem and it seems to be working well. Maybe we're missing something? 

 

I'm not aware of any GC issues in the platform. 

Link to comment
Share on other sites

Thanks for testing it. I just wanted to confirm that I'm not doing anything wrong code wise. I'll try testing it on another computer in case it's some kind of weird setup issue or something.

Link to comment
Share on other sites

Hi again,

 

I'm still trying to figure out what's going on, as I'm getting inconsistent results with further testing. To eliminate a few possibilities could you please tell me how you viewed the test example I provided; did you do a "publish preview" inside Flash Pro or did you use a Standalone Flash Player?

 

Thanks for your time.

Link to comment
Share on other sites

I got the same results as Jack using Flash Pro "publish preview"

 

I just did another test in a standalone player and the memory never exceeded a max of 16.

Link to comment
Share on other sites

Thanks Carl, but I don't know what's going on with my version. I get the same "publish preview" results as you (doesn't pass 30), but inside the standalone player it just continues to rise over 100. I've attached profiler results below that show over 100 captured loader instances too, whereas without the tween it doesn't go above 2 instances.

 

Could I ask a favour?, could you please redownload my test swf I posted earlier and run it in the standalone player (but don't compile it with your Flash Pro at all), and let me know the results?. I just want to rule out possible compiler options or something!?!! Also, would you then be able to compile a version with your Flash Pro and send me the swfs and I'll test on my end?

 

I'd greatly appreciate your assistance with this, thank you.

 

Profiler_Results.png

Standalone_Player_Results.png

Link to comment
Share on other sites

i opened your original swf in a stand alone player and did not see any new behavior.

 

Below is a swf I compiled from Flash Pro yesterday

VideoDisposeTest.swf.zip

Link to comment
Share on other sites

Thanks, but were you using a mac? Perhaps it's a windows issue?, because I've tried it on 3 different windows computers and they all do the same thing (don't have access to mac) .

 

Here's what I've discovered so far (using latest greensock version):

  • It only seems to happen on standalone and Air desktop players ("publish preview" in Flash Pro and web plugins work fine).
  • Happens in all standalone player versions I've tested from 10 to 12.
  • Happens when a tween is attached to a video, image or swf content or using dispose with flush content ie: vidContainer.dispose(true);
  • Using native AS3 tweens don't do it.
  • Here's another strange one, if a tween is also on the parent swf it doesn't do it.

This is just really baffling. If I didn't have to use the standalone players or Air for Desktop I wouldn't mind, but unfortunately my projects require it.

Link to comment
Share on other sites

Sure sounds like an Air (or Flash Player) bug. I'm not sure there's anything we can do to help you here unfortunately. And yes, Carl and I are both on Macs. Obviously the GreenSock code is identical regardless of the platform, so if you're seeing a glitch only on the PC side, that's an even stronger indicator that it's a bug on Adobe's end. :(

Link to comment
Share on other sites

Yeah I initially thought it may have been a Flash "bug", but then it seems to work just fine when using the native classes. Even Tweener works great, so how does that add up?!. When using Greensock it's almost like the tween is holding onto the loader for some reason, hence the memory build up.

Anyway, thanks for your help. I guess I'll just have to find some other way around it, even if it means placing a "dummy" tween on the parent. Seems like a real waste of code though.

Link to comment
Share on other sites

Keep in mind that in order to improve performance, the tweening engine hangs on to a reference of the target for up to about 2 seconds after its last tween finishes, so it's normal not to see the memory usage subside immediately. And make sure you're not hanging on to a reference of the tween after you're done with it, as that would obviously contain a reference to the target. Beyond that, I'm not sure what could be causing the issue, but we've had some GC experts look at GSAP and verify that it does a good job. 

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×