Jump to content
GreenSock

pol

How to load and free up resources?

Recommended Posts

I'm using LoaderMax to load 3 SWFs. After they are loaded, I want to essentially store them in separate movieclips that are rendered on the timeline at different times, so that memory resources are preserved.

 

Is there a way to unload the loader and keep the loaded SWFs (essentially like a library symbol) - embedded in separate website page movieclips on the timeline, so that when the website changes pages by changing frames, the loaded SWF that goes with the old page is freed from memory without having to reload it again the next time the page is rendered?

 

Does that make sense?

 

Thanks so much,

Pol

Link to comment
Share on other sites

I wish it was that simple. Did you check my post? "unload and cleanup" Not exactly the same but close enough the goal is to load and use several swf without causing memory issues.

Link to comment
Share on other sites

Hi Asseb,

 

I searched through your posts, but didn't spot anything substantive. I'm familiar with unloading and cleaning up. There isn't much in these to cleanup (no event listeners, no audio, no video, just images and animation which is already stopped).

 

I suppose what you are saying is that I should reload these each time their corresponding webpage is selected? That seems like a lot of loading and unloading. There is no other way?

 

I ask because when they were part of the same movie, on each page's timeline, the memory issue wasn't there. So where do they go when they are just sitting in the library? That can't be emulated after loading?

 

Thanks a bunch,

Pol

Link to comment
Share on other sites

I suppose what you are saying is that I should reload these each time their corresponding webpage is selected? That seems like a lot of loading and unloading. There is no other way?

Either the assets are in memory or not. Maybe I misunderstood your comment/question though. As far as it being a lot of loading/unloading, keep in mind that typically you'd only need to worry about the FIRST load because subsequent loads would come directly from the browser's cache which is extremely fast.

 

I ask because when they were part of the same movie, on each page's timeline, the memory issue wasn't there. So where do they go when they are just sitting in the library? That can't be emulated after loading?

What do you mean by "the memory issue wasn't there"? What memory issue? If you build stuff on a MovieClip timeline like that, I'm pretty sure that it does indeed get loaded into memory (along with the rest of the swf). Particular assets/frames may not be rendered to the screen at certain times, but that doesn't mean they're not in memory.

Link to comment
Share on other sites

Thanks this helps.

 

The "memory issue" was that only one of the movieclips was active or existent on the timeline at one time, so all three were never bogging down resources at one time. In my current pre-loading scenario, all 3 are pre-loaded and it seems to bog down resources. I don't know how to pre-load into a MovieClip that is yet on stage? If I could magically do that, I think I would be fine?

 

Two questions:

1. Is there a way to load something into a MovieClip that is in the library but not yet rendered on an active frame?

2. Should unload or dispose be called after each load is complete?

 

Thank you!

Link to comment
Share on other sites

1. Is there a way to load something into a MovieClip that is in the library but not yet rendered on an active frame?

Not really - you can define actions for a particular frame I believe, but you can't place an object on a frame dynamically at runtime with ActionScript. I wouldn't advise doing that even if you could, though.

 

I wonder if the issue you're seeing doesn't have anything to do with memory per se, but rather code execution. In other words, when you load a swf, it immediately executes the code on the first frame and starts playing the swf as soon as the Loader's INIT event is dispatched (when the first frame loads fully). If you have a bunch of swfs playing, it could bog down resources. One solution would be to just dispose(true) them as soon as they load so that they're in the browser's cache, ready to load very quickly when you need them.

 

2. Should unload or dispose be called after each load is complete?

It depends on whether or not you plan to reuse that loader instance to load() the content at some point. That's completely up to you. If you dispose() a loader, though, you cannot reuse it. Think of it as dead. In your case, it might be best to just use an onComplete to call dispose(true) as soon as it loads if you're just trying to get it into the browser's cache.

Link to comment
Share on other sites

Thank you.

 

This helps a lot. Two questions:

 

1. What is the advantage of re-using a loader? (unload vs dispose) - ie how much resources are taken up re-instating a new loader?

 

2. When I used unload on a MaxLoader loading 3 SWFs, it oddly began loading the same 3 SWFs all over again? Is that what it's supposed to do, and if so, what would clarify why for me to better understand the paradigm?

 

Thanks so much,

Pol

Link to comment
Share on other sites

1. What is the advantage of re-using a loader? (unload vs dispose) - ie how much resources are taken up re-instating a new loader?

In the vast majority of use cases, it's completely inconsequential. Unless you have literally thousands and thousands of loader instances, I doubt you'd notice any difference whatsoever in terms of memory. Frankly, in most situations, I'd probably just create a new loader instance whenever you need one rather than reusing instances. Some of the settings can only be set through the constructor's vars parameter anyway, so it's cleaner to just create a new instance unless you're loading the same file again in which case I'd definitely recommend reusing the same loader. In other words, you can load() and unload() at will.

 

2. When I used unload on a MaxLoader loading 3 SWFs, it oddly began loading the same 3 SWFs all over again? Is that what it's supposed to do, and if so, what would clarify why for me to better understand the paradigm?

Absolutely not. I suspect there's something else going on in your code that is causing the LoaderMax instance to load() again. Could you post a very simple example of the behavior you experienced? I'd really like to see it.

 

Also, I'd always recommend making sure you've got the latest version of the classes. http://www.greensock.com/loadermax/

Link to comment
Share on other sites

Thank you. I'll post an example if I can re-create the behavior. I should be back to that part of the project tomorrow.

 

In the mean-time. I have a very basic question that will help me a lot:

 

1. What is the advantage of loading and unloading a SWF each time it is used versus just keeping it in memory after the first load? I have SWFs that are around 1MB in size and they are used on an intermittent basis. Is that 1MB an issue for memory usage? What kind of memory usage ranges should I be weary of before I more aggressively unload SWFs that I loaded rather than leaving them in memory?

 

2. Could you clear up which of the methods totally removes each of the following: (unload, dispose(true), etc)

a. Removes the loader completely and frees the memory affiliated with it -- but not the SWF (or item) loaded?

b. Removes the loader completely and frees the memory affiliated with BOTH the loader and the SWF (or item) loaded?

- How would I code (a) and how would I code (B)?

 

Thank you so much. Your assistance is making a big difference for me,

Pol

Link to comment
Share on other sites

1. What is the advantage of loading and unloading a SWF each time it is used versus just keeping it in memory after the first load? I have SWFs that are around 1MB in size and they are used on an intermittent basis. Is that 1MB an issue for memory usage? What kind of memory usage ranges should I be weary of before I more aggressively unload SWFs that I loaded rather than leaving them in memory?

There isn't a "right" answer for that - it all depends on your target audience, what type of devices they're using, etc. I'd recommend doing some tests on your lowest common denominator devices. For example, if people will use your app on a modern desktop system, it can handle MUCH more than a mobile phone could.

 

2. Could you clear up which of the methods totally removes each of the following: (unload, dispose(true), etc)

a. Removes the loader completely and frees the memory affiliated with it -- but not the SWF (or item) loaded?

b. Removes the loader completely and frees the memory affiliated with BOTH the loader and the SWF (or item) loaded?

- How would I code (a) and how would I code (B)?

a. dispose(false) just disposes the loader itself, not the content that it loaded.

b. dispose(true) disposes both the loader and the content it loaded.

 

Do you still need to know how to code them? It's literally as simple as calling the dispose() method on the loader instance. And for the record, unload() will dump the content that was loaded but keep the loader in tact so that you could load() again.

Link to comment
Share on other sites

Oh! Thank you... that clarifies a lot.

 

Now I understand the difference between dispose and unload. I really appreciate that.

 

My target audience is computers (as I don't have a phone app version yet). So it will be laptops and desktops with a minimum of 1G RAM. My core target audience will have higher end hardware. Any thoughts on whether a few MBs loaded will be inconsequential rather than loading and unloading?

 

Thanks,

Pol

Link to comment
Share on other sites

A few MBs will probably be inconsequential, yes, but I'd always recommend testing on your own to verify the theory :)

 

Good luck.

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.
×