SWF loading

[sandesh]

Hi..... I am new to this so pls help me out

 

I have 2 fla files. One is the preloader fla and the other is the main fla.

In the preloader fla, I load the main file using the loadermax component, which is happening fine.

However, within the main fla, I am loading a XML file and a image file.

Since I am reading the background file name from the XML file, I have created 2 loadermax instances (1 for XML & 1 for image).

Inside the complete event handler of the XMLLoader, I am creating the loadermax instance for the image.

 

Everything is working fine, but the problem is that when the preloader loads the main swf, it only considers the loading of the XML. When the xml is loaded, the swf file is considered as loaded and it doesn't consider the loading of the image. I have also tried the requiredWithRoot property with the parent loadermax instance, but it doesn't seem to work

I have attached the files......

[GreenSock]

There were several problems with your code:

 

1) You misspelled "requireWithRoot" by adding a "d" where it wasn't needed - "requiredWithRoot". This was the root of your problem (get it? "root" of your problem? I crack myself up)

 

2) You were adding new loaders into the queue when it completed but remember that when it completes, the SWFLoader is notified so it's better to add your loaders when the INIT event gets fired by the XMLLoader which occurs before the COMPLETE event fires.

 

3) You had a bunch of extra LoaderMax instances as well as funky code where you paused and then immediately resumed loading.

 

4) You gave the same name to multiple LoaderMax instances (names should be unique). This didn't necessarily cause issues in your particular case, but I figured I'd mention it.

 

5) You used Math.round() on your randomized index value instead of Math.floor() or int() which sometimes caused the index value to be invalid. For example, if you have an array with 4 elements (index 0-3) and you do Math.round(Math.random() * 4) and Math.random() is a really high value like 0.999 then the result will be 4 instead of 3.

 

I've attached the corrected version. Hope that helps!

[sandesh]

Thanks for your prompt reply and the corrected files, Greensock....

I realised where i went wrong .... It now works

[sandesh]

Hi Jack,

 

I am having problems regarding the loading progress of my files. Considering the same corrected files that you gave me, I am unable to make the loading progress bar to assume the size of XML + background image in the loaded swf. What it does is when it loads the xml files, the loading bar resets to display the progress of the background image.

 

I have checked the forums and found the same problem which have been faced by others. I tried the 'estimatedBytes' as well as 'auditSize' property in the loaderMax instance of the preloader.

But it doesn't seems to be working

[GreenSock]

I've attached a fixed version. I did have to make one very small update to SWFLoader to accommodate a rare situation (the online version has been updated as well). Thanks again for putting together the example FLAs - they were very helpful in identifying the issue!

[sandesh]

Hi Jack......

 

Thanks for this version. But still I didn't like the idea of putting the estimated bytes in 3 places (for SWFloader, XMLloader & ImageLoader).

The main problem in using this is, when the bg image loads as part of the main file, the bg is a random image which is read from the xml file.

So the image size is not known in advance and the progress bar will either not complete fully or will stay on till the bg image loads (depending on the bg image size), if I give some hardcore value for estimatedBytes.

So I was looking for a more dynamic solution and tried using the auditSize property for Loadermax instance, but it doesn't seem to work.

I hope you have understood my point ....?

[GreenSock]

Sure, you can use the auditSize feature, but since it's impossible for it to know the size immediately, your progress value will jump ahead and then when the size is audited properly, it will decrease back down to reflect the newly discovered size. In other words, let's say your XML file is 400 bytes and you've got dynamic stuff you add later that's 300000 bytes worth of image. If you don't define any estimatedBytes, LoaderMax has nothing to go on, so it will load your XML and the progress will be based on the XML files size (400 bytes in this example). When all of the XML file has loaded, the loader's bytesTotal and bytesLoaded will technically be 400 (100% progress) but XMLLoader is smart enough to reduce the bytesLoaded slightly (like 1%, making progress 99%) until the XML has been initialized and the INIT event is dispatched (because there may be other dynamic loaders in there so it doesn't want to show 100% prematurely). Your loader will look like it's 99% done at that point, and then BOOM it gets these other dynamic loaders inserted that are 300000 bytes worth, meaning the overall progress is now MUCH less (400 bytes out of 300400). That's the beauty of the estimatedBytes solution - it allows you to prevent (or minimize) that jumping ahead and back of the progress value. And don't worry - your estimatedBytes is exactly that - an ESTIMATE. So don't worry if all your images are different values. If you know you'll be loading roughly 300000 bytes worth of image, great. Once LoaderMax loads enough of the file to determine the REAL bytesTotal, it will dump the estimate and use the accurate value.

 

Again, it's absolutely impossible for LoaderMax to immediately know how big all your nested loaders are. If you've got some fancy way of solving this dilemma that is more elegant than estimatedBytes, I'm all ears.

[sandesh]

Hi Jack.....

 

Now I get your point... I was relieved when i read the last line above (it will dump the estimate and use the accurate value).

Now I came across a new bug..... In the latest corrected version which you send me, I didn't want to use the estimatedBytes in 3 places.... so i just mentioned in 1 place in the preloader

code -- queue.append(new SWFLoader("LoadingExample.swf", { name:"main", estimatedBytes:380000 }));

I hope that's ok ...... now If i view this in Firefox and IE, it works fine......

but if i view it in Chrome, the image never loads completely, It happens for any image (does not display completely)...... but the image shows if i enable back the estimatedBytes in ImageLoader.

I have seen that this problem occurs only if i remove the estimatedBytes from ImageLoader, even though I have the estimatedBytes in my preloader file.

 

So is this a chrome problem? I have attached a zip file containing screenshots of all the 3 browsers.

[GreenSock]

Hm, I can't seem to reproduce that problem. Very weird - what platform are you on? Mac? Windows? What version of the Flash Player? Does your server have gzip enabled? (There are bugs in the the way Chrome and Firefox handle files that are received from servers with gzip enabled in certain scenarios). Have you tried setting auditSize:false on your LoaderMax (just for kicks)? Can you point me to an example online that I can see? I've already tried with the files you posted but everything works great for me in all browsers, so I'm having a hard time troubleshooting.

[sandesh]

Hi Jack....

 

what platform are you on? Mac? Windows?

Ans : Windows

 

What version of the Flash Player?

Ans : Flash Version 10.1.53.64 Chrome version : 5.0.375.125

 

Does your server have gzip enabled? (There are bugs in the the way Chrome and Firefox handle files that are received from servers with gzip enabled in certain scenarios).

Ans : Not Sure

 

Have you tried setting auditSize:false on your LoaderMax (just for kicks)?

Ans : Yes. But still the same problem

 

Can you point me to an example online that I can see?

Ans: http://www.grandmotherindia.net/wip/rnd ... ader2.html

 

 

Also I have attached the source files of the above example. I have made some minor changes from the original one, so pls refer to this one

[GreenSock]

It definitely looks like an issue with your server. I uploaded your files and they worked fine on my server:

http://www.greensock.com/temp/Loader2.html

 

Also you didn't set auditSize:false on your nested LoaderMax instance inside LoadingExample2 (_mainqueue). Please try that and upload the change to your server and see if that makes any difference. My guess is that when it audits the size of your image, it cancels the load immediately when it loads enough data to determine the bytesTotal (typically almost instantaneously) but maybe if gzip is enabled on your server Chrome burps when it tries to load the full data. Maybe Chrome tries to be helpful and says "oh, wait, you already requested that file...let me get it from my cache" (even though only part of the image is there) and then when it tries to compare the sizes it gets confused by the gzip compression applied by your server. I dunno - just a guess at this point. But like I said, it works fine in Chrome from my server.

[sandesh]

Hi Jack,

 

The problem finally seems to be solved in Chrome.

I actually had written auditSize:false in the wrong place.

Instead of writing it for the mainqueue loadermax instance, I had written for the loaderMax instance in the preloader.

But now I have written it in the correct place, and its now working in Chrome too...

 

Thanks for all your help .......

[GreenSock]

Sure, glad to help. But it still does point out a problem with Chrome (or the Flash Player that's specific to Chrome). I hate that kind of thing. But yeah, setting auditSize to false solves it.