Hello All.
I’m having a pretty significant performance issue with multiple instances of the same external files. The description of the problem should give you the idea of what is going on, but if you need any other info, please let me know. I definitely need help here, sooner than later.
Subject:
A portfolio project with a master portfolio.swf file, which pulls in 6 instances of project.swf and thumb.swf into targetClips (projectClip[1-6] and thumbClip[1-6], respectively). A variable (projectNumber) is passed to the project.swf and thumb.swf movies through the loadMovie URL so that they know what project they are associated with. The projectNumber variable is also used by each projectClip instance to pull in the right external JPG image files for the portfolio also using loadMovie.
Issue:
As the portfolio.swf file loads, the project instances and thumbs are all preloaded in order (1-6) into their targetClips. Each projectClip loads its associated .jpgs as well. The issue lies in the performance of the different instances of the projectClip. They seem to slow down depending on load order (projectClip1 is snappy, projectClip4 is noticably slower, etc.). The more noticeable issue is that projectClip5 and project Clip6 completely choke: they don’t play the tween that exists at the label that they are supposed to go to, and they seem to load the external jpgs on the fly, even though they should be preloaded (the thumb.swf file waits to show up until the project images are completely loaded).
Would somebody be so kind as to take a stab at what might be going wrong? It would be greatly appreciated. Caveat: the jpg files suck - they are only placeholders.
The button hides all of the projectClips, tells all the button highlights to disappear.
Then, it gets rid of it’s own clickable state:
gotoAndStop(“nobutton”);
Turns on its own highlight:
with (highlightClip) { gotoAndStop(“on”); }
Then it tells its projectClip to present the first image based on the variable it has been passed:
myProjectClip = eval("_level0.ProjectClip"+projectNumber);
myProjectClip.gotoAndPlay(“one”);
}
Nothing too crazy, except for the fact that I am telling all of the different instances to turn off first before we turn our specific one on.
It reminds me of that java syncronization problem were it locks up if several multithreads try to access the same memory spaces and they wait for the other threads to open up.
Does this happen when you test using ctrl+enter with the fla open?
Unfortunately, we can’t test it in Flash because we are passing the variable in through the URL (URL?var=projectNumber). That only works in the browser.
We get the same issue on any workstation (at a variety of processor speeds and memory allocations).
I’ll try yanking out some of the code that might be bumping into itself and see if that helps.
Well, the projectClip control code that is hooked into the button is now even more dynamic. So, in addition to talking to its project via a projectNumber varialbe, it now turns off all of the clips except for the one that needs to be presented (it used to turn off all of the clips and then request that the clip that is needed be presented after that).
Unfortunately, this didn’t help. We were assuming that there were collisions in telling the clip to turn off, and then a couple of lines of code later telling it to turn on, but that doesn’t seem to be the issue. No change in the end result: projectClip4 runs slowly, projectClip5 and 6 don’t run at all.
Any other angles on this issue that you can think of?
Thanks for your help everyone. We went in a different direction and just loaded the first project into the projectClip and then on click load other projects into the same clip, rather than loading into the 6 different clips. In the end, it works quite well.
