Jump to content
Search Community

Loading bar flashes with nested swfs in xml

brendynz test
Moderator Tag

Recommended Posts

Im hoping this is just a small param I am missing. Im loading in an XML file, which has the following line in it to load a swf:

 

 

Everything is working fine, except the loading bar flashes 100% full, and then reverts back to 0% to load the swf. Obvisouly it's better if it takes both the XML filesize and SWF filesize into account. I've tried to compensate for that my adding an onComplete into the XMLLoader, but that doesn't seem to fire until both the SWF and XML are loaded. Any thoughts on a better way to do this so the bar doesn't flash?

 

protected function setLoaders():void {

_isXMLLoaded = false;

_loaderMax = new LoaderMax( { name:"mainQueue", onProgress:loaderProgressHandler, requireWithRoot:true, noCache:true, onComplete:loaderCompleteHandler, onError:loaderErrorHandler, onIOError:loaderErrorHandler, onFail:loaderErrorHandler } );

_loaderMax.append( new XMLLoader("myXML.xml", {name:"lib_xml", estimatedBytes:3000, onError:loaderErrorHandler, onIOError:loaderErrorHandler, onComplete:initLoader}) );

LoaderMax.prioritize("lib_xml");

_loaderMax.load();

}

 

private function initLoader( $evt:LoaderEvent ):void {

_isXMLLoaded = true;

}

 

private function loaderProgressHandler( $evt:LoaderEvent ):void {

if(_isXMLLoaded) {

showLoadProgress( $evt.target.progress );

} else {

trace( "LOADING XML:", $evt.target.progress );

}

Link to comment
Share on other sites

i'm not an expert on requireWithRoot, but I believe you are mis-using it.

 

in most of documentation that i'm familiar with requireWIthRoot is used when a child swf's loading progress is being used in determining the loading progress of its parent.

also, it defines what the parent is and is not a true/false value.

 

Again, I haven't used it myself, just sharing what I've read.

 

From what you are describing, I think you can get away with not having a LoaderMax that contains an XMLLoader that creates your SWFLoader.

 

Just using the XMLLoader on its own should be sufficient.

 

from the XMLLoader docs:

 

The XMLLoader's progress will automatically factor in the dynamically-created loaders that have the load="true" attribute and it won't dispatch its COMPLETE event until those loaders have completed as well

 

http://www.greensock.com/as/docs/tween/ ... oader.html

 

I do agree it would be useful to know how to make it work with your existing set up.

 

 

on further investigation, your XMLLoader's estimated bytes should include the size of the file AND any other loaders that it contains.

maybe this will solve the issue. perhaps that 3000 is throwing things off.

 

estimatedBytes : uint - Initially, the loader's bytesTotal is set to the estimatedBytes value (or LoaderMax.defaultEstimatedBytes if one isn't defined). Then, when the XML has been loaded and analyzed enough to determine the size of any dynamic loaders that were found in the XML data (like nodes, etc.), it will adjust the bytesTotal accordingly. Setting estimatedBytes is optional, but it provides a way to avoid situations where the progress and bytesTotal values jump around as XMLLoader recognizes nested loaders in the XML and audits their size. The estimatedBytes value should include all nested loaders as well, so if your XML file itself is 500 bytes and you have 3 tags with load="true" and each image is about 2000 bytes, your XMLLoader's estimatedBytes should be 6500. The more accurate the value, the more accurate the loaders' overall progress will be.

Link to comment
Share on other sites

Thanks for the help on this :)

 

I've tried a whole bunch of combinations with estimatedBytes on both the LoaderMax instance, and the XMLLoader instance, as well as using the XMLLoader by itself, and Im still getting a jump unfortunately. If I change the estimate btyes to a higher amount on the XML, it just seems that the first loader bar takes twice as long before it gets to the second one.

Link to comment
Share on other sites

Tough to say exactly what's happening without seeing your FLA and support files, but it sounds like you just didn't set the XMLLoader's estimatedBytes accurately. As Carl suggested, it is supposed to include the XML file's size itself AND any subloading files. So if your XML file is 3k (3072 bytes) and your swf is 200k (204800 bytes), your XMLLoader's estimatedBytes would be 207872 (the sum). You only set yours to 3000 which is extremely small.

Link to comment
Share on other sites

Thanks for the response guys

I played with a bunch of estimated byte sizes and it's still happening, so Im not sure what the issue is. If I just put the estimated size to several megs even though the file is only at 100k, I know that would be overkill, but shouldn't that solve the issue?

Link to comment
Share on other sites

I've figured out the issue. I had the estimatedBytes line in both my actionscript and the xml file:

 

_loaderMax = new LoaderMax( { name:"mainQueue", noCache:true, onProgress:loaderProgressHandler, onComplete:loaderCompleteHandlerr } );

_loaderMax.append( new XMLLoader("xml/data_en.xml", {name:"lib_xml", estimatedBytes:10000 }));

_loaderMax.load();

 

 

As soon as I removed the estimatedBytes from the XML file, it worked properly.

 

Is this a known bug?

Link to comment
Share on other sites

As soon as I removed the estimatedBytes from the XML file, it worked properly.

 

Is this a known bug?

Nope. I don't see the bug - could you upload a simple set of files (an FLA, .xml, and .swf) that demonstrates the "bug" so that I can publish it on my end and see what's happening? Is the .swf that you're subloading really only about 9.8k (10000 bytes)? And if you set your XMLLoader's estimatedBytes to 10000 and your is also 10000, that cannot be accurate because that would mean the XML file is 0k - remember that the XMLLoader's estimatedBytes should include the XML file itself's size as well as any subloading files' size. In any case, a sample set of files would be super helpful in identifying the issue. The simpler the files the better.

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.
×
×
  • Create New...