2-3 second delayed start to loading images via ImageLoader compared to DataLoader

[andytwoods]

Hi there,

any thoughts on why this is so?  Tempted just to use the DataLoader and process the dataarray myself
Cheers,
Andy.

[Carl]

No, all loads should happen as soon as load() is called on any loader type.

In some cases the audit may add a fraction of a second, but you would rarely notice it on a single image. Would be very interested in seeing an example of this. Feel free to send an simple example.

 

As evidenced in the demos here: http://www.greensock.com/loadermax/

and  here: http://www.snorkl.tv/2011/08/loading-images-with-loadermax-load-and-track-the-progress-of-multiple-images/ the load starts immediately.

[andytwoods]

Hi there,

 

going on a run but for quick eg's:

 

50ish videos: http://www.opensourcesci.com/experiments/Captavatar/

100ish pics  : http://www.opensourcesci.com/experiments/CaptavatarFace/

 

Note that the LoaderMax indicator shown in the swfs at these urls is as below.

 

Cheers,

Andy.

 

 

[Carl]

Yeah, the delay on the images is clearly the audit. Each image gets partially loaded (just enough to get file size) and then immediately cancelled. With 100 images its perfectly normal for that time to compound into a few seconds (depending on network latency).

LoaderMax docs: http://api.greensock.com/as/com/greensock/loading/LoaderMax.html

 

auditSize : Boolean - By default, when the LoaderMax begins to load it quickly loops through its children and if it finds any that don't have an estimatedBytes defined, it will briefly open a URLStream in order to attempt to determine its bytesTotal, immediately closing the URLStream once the value has been determined. This causes a brief delay initially, but greatly improves the accuracy of the progress and bytesTotal values. Set auditSize to false to prevent the LoaderMax from auditing its childrens' size (it is true by default). For maximum performance, it is best to define an estimatedBytes value for as many loaders as possible to avoid the delay caused by audits. When the LoaderMax audits an XMLLoader, it cannot recognize loaders that will be created from the XML data nor can it recognize loaders inside subloaded swf files from a SWFLoader (it would take far too long to load sufficient data for that - audits should be as fast as possible). If you do not set an appropriate estimatedSize for XMLLoaders or SWFLoaders that contain LoaderMax loaders, you'll notice that the parent LoaderMax's progress and bytesTotal change when the nested loaders are recognized (this is normal). To control the default auditSize value, use the static LoaderMax.defaultAuditSize property.

Also check out the LoaderMax tips and tricks page for more info on getting accurate and smoothe progress: http://www.greensock.com/loadermax-tips/

To see the audits taking place, view your pages in Chrome. Open dev tools and click on the "network" tab. You will see all the cancelled loaders in red.

Hope this helps.

[andytwoods]

thanks for that