Cleanest way to remove a panorama via code?

[mr_sav]

Hi All,

After following the tutorials, i have got a panorama being created inside a flash movie by using the following

var panorama:MovieClip;
panorama = loader.content;
panorama.setArea(0,0,700,500);
panorama.loadPanorama("panoName=panoramas/rooms/" + strPanoFiles + "&xml_file=" + strPanoXML);

My question is, what is the best way of removing this panorama through code? I have tried the following:

removeChild(loader);

But this doesn't seem to be very 'clean', as if this executes when the user is still dragging the panorama around, the quality doesn't revert back to _high and the rest of the Flash movie remainsl at a low quality. Also, trying to run the same code again to create a new one creates error messages?

Thanks
Chris

[zleifr]

removeChild(loader);
loader.unload();
loader = null;

BUT, to the best of my knowledge there is no absolutely perfectly fail-safe guaranteed method to do it, especially if plugins and various other .swf files get involved, which don't clean up after themselves properly

[robrockyeah13]

I made the same of you "mr sav" and i have the same problem.
I have a main menu to go to the page with the panos, but if i come back to the main menu, the pano stuff is not very clean, and if i come back to the pano page everything is going really slow.
Come on, is not possible to solve this problem????

[Trausti Hraunfjord]

Come on, is not possible to solve this problem????

This needs to be fixed at the Adobe labs. They need to change the way Flash works. Until that happens, we will have to live with this.

[cheathamlane]

Tuddi:

Exactly what are you referring to that needs to "be fixed at Adobe"?

It's my understanding that poor management of Garbage Collection is a fault of the person doing the scripting, and not anything Adobe's doing. (and believe me, I've fallen prey to my own mismanaged garbage collection)

?

[Trausti Hraunfjord]

You can order the garbage collection to pick up what is not used, but it will not do so immediately. It may take milliseconds (won't bother anyone much) or it may take several seconds, and clog up memory and be a pain.

That is not something you can rule over with scripting. You can give the command "removeChild" or whatever... and that's it. After you have given the command(s), it is upto the garbage collector to do it's job, and unfortunately it doesn't respond instantly.

That is what needs to be fixed over at Adobe.

Read HERE (http://www.adobe.com/devnet/flashplayer/articles/garbage_collection.html)to understand what I am piss-poor at explaining.

[cheathamlane]

:)

I've seen that article... And believe me, once you get really intent on removing things and cleaning up after yourself in your own code, Garbage Collection becomes a non-issue. By "you" I mean any of us doing the scripting.

That said -- I think the real issue here is not being able to clean up after FPP properly -- we only have so many hooks in to FPP's internals, and ultimately don't know what's going on inside.

Our SWFs and things which we add to or wrap around FPP might be super "clean", but the final presentation is going to still have the FPP factor going on.

[Trausti Hraunfjord]

Quite honestly, I wouldn't know :) But I have seen how the garbage collector can wait quite a while before doing it's job.

Yes, there are ways to get it's attention, but it should react instantly, and I am sure Adobe will make it faster in upcoming versions.... ok... "sure" is maybe a bit optimistic, but one can hope.

And I agree that the problem might also be with "us" and FPP.

[cheathamlane]

"I" agree... ;)

But, part of the headache of the "mark and sweep" approach, as outlined in your link above, is that it takes a lot of memory and processor overhead; so making it "faster" doesn't mean we'd ultimately benefit.

[Rick Workman]

Just to elaborate on Patrick's response:

1. Writing a correct and efficient garbage collector is hard, and the consequences of getting it wrong are pretty catostrophic (memory leaks or memory corruption). However, knowing *when* to run it, in the absence of any real knowledge of the dynamic characteristics of the program, is pretty much a black art. If you don't do it often enough, you'll potentially waste memory (at least for a while); too often and you waste a lot of CPU cycles looking through all of the allocated memory for garbage that doesn't exist. Adobe shouldn't change anything without hard evidence that such changes will benefit most AS3 programs, and be harmful to very few.

2. The AS3 programmer can (must?) assist in garbage collection, first by helping to identify garbage (see "Resource management strategies in Flash Player 9" referenced by the paper), and second by not creating garbage in the first place. Every "new", with the possible exception of initialization code that's only executed once, needs to be assessed as when and how it will get "disposed". Similarly with every addEventListener, as noted in the paper.

Identifying and fixing memory leaks in a system like this is difficult because there are several layers: the AS3 VM, FPP, various plugins, other AS3 code, and finally the XML. I think anybody dealing solely with XML shouldn't have to worry about memory with the following exceptions:

a) large images (pans, hotspots) and movies - pretty obvious
b) recursive loops caused by functions directly or indirectly calling themselves

A "well behaved" XML , which avoids these pitfalls, should load and execute indefinitely without running out of memory. Taking it one step further, assuming:

a) a "well behaved" XML, and
b) no clever optimization in which FPP recognizes it's re-loading the same xml

it should be possible to set up, e.g., using onTransitionEnd handler, an XML which indefinitely reloads itself without ever running out of memory. (Well, OK, it may take twice as much memory to do the reload while the original is still in memory, but if you can do it once, it should run forever.)

If condition b) cannot be met, it may be necessary to introduce a second XML which forms a "load loop", i.e., XML1 loads XML2 loads XML1 ...

Now I think if this doesn't work, there's a bug. It may be in the AS3 VM, but more likely it's in FPP or one of the plugins. Collectively we need to identify such bugs so they can be at least well documented, with any workarounds, and/or (hopefully) fixed.

Now this doesn't help a lot in figuring out what to do in AS3 to workaround issues in FPP (the original poster's problem), but it may provide a way for proving such issues exist, so they can be addressed by whoever's responsible.

Sorry for the length of this reply, but I really think it's important to track down any such bugs in the FPP/plugin layer.

Rick

[cheathamlane]

What Rick said!

:)

[Rick Workman]

Having philosophized at great length, I thought I should be drinking my own Kool-Aid. So here's what I did:

Created a looping test in XML (MT1.xml):

<panorama>
<parameters>
panoName=Media/Pans/TestPan
panoType=mov
</parameters>
<hotspots>
<global
onTransitionEnd="timer+=1,1000,,reload"
reload="loadPano(xml_file=MT1.xml,0,none)"
>
<pano
/>
<spot id="dummy"
/>
</global>
</hotspots>
</panorama>

So this sets a timer onTransitionEnd at the entry to the pan and when the timer expires reloads itself. I set up all my plugins and initial values in a startup xml file, prior to loading this one.

To report results, I wrote a very simple (and crude) plugin which creates a scrolling txt field in top left corner of pan area and then writes the current memory usage every time a new pan is loaded. (I needed to do this because it appears garbage collection doesn't seem to run inside the Flash CS3 development environment where trace can be easily used. I haven't tried the Debug Player, but I think running it in the standard player gives the test a bit more credibility.)

Bottom line is that for simple cases (one pan and two pan loops with minimal content), FPP and Hotspots plugin don't leak a significant amount. I detected maybe a MB in a thousand iterations, and certainly some of that is my plugin's scrolling text. IMO, this is very good news, although the xml content is very minimal (single trivial hotspot), so I'm going to run this from time to time on more complicated tests cases.

So my approach from an AS3 perspective (to get back to the original question), is to initialize an FPP environment with hotspots plugin, then use "panorama.externals.hotspots.execute" to control everything, since that seems to work just like calls inside XML, and that looks pretty safe. I think this implies, you never unload anything, just load new stuff and old goes away "automagically". From the original description, I can't tell whether this approach would work for mr_sav (Chris).

Sorry for another long post,

Rick

P.S. If anybody's interested in using my crude plugin for their own testing, send me an email. (I haven't quite figured out how to use attachments in this forum.)

[cheathamlane]

I've been working with a set of classes to handle loading of multiple files of disparate file types (queueloader), and here's what the creators say:

There is a bug with the System.totalMemory property. It does NOT work in the flash IDE, so test in a browser

This is as of January, so may still be good info.