Yes, that's it, and it can certainly improve network performance too. Imagine you have a list (not using virtualRenderers) with 2000 images. Do you want your mobile to open 2000 http connections and try to load 2000 images at once? That would take a while, and it's much faster (both visually and timely) to download only 3-4 at a time: that's what queueing does :) (there's was a maxActiveRequests with a default of 2 somewhere alongside with the enableQueueing). Plus, http servers usually limit the maximum number of connections per client, so if you do 2000 request most of them will timeout and fail, or just get rejected.
When using virtualRenderers (and depending on your content size), it might as well be useful, since you can control the queue and cancel the download if the item has gone offscreen (that HUGE gif animation you skipped up must stop hogging your bandwidth, since it's more important to load now the beautiful and tiny JPG you are looking at). Destroying / recycling the virtualRenderer doesn't mean the connection to download it's content is also stopped/canceled as well. Have a look at activeRequests and requestQueue lists on runtime to get an idea :) (and even to priorities for prioritizing some contents above others in the queue). Hope it helps :) http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/spark/core/ContentCache.html#activeRequests On Fri, Sep 1, 2017 at 1:51 AM, Erik J. Thomas <e...@linqto.com> wrote: > Hey bilbosax: > > I've never used queueing functionality and you're right there's not much > written about it. But by the properties you can set it appears that you can > limit the number of simultaneous loads to reduce bandwidth demands. I don't > see much use for that myself. > > Cheers, > > Erik > > On Aug 31, 2017, at 3:11 PM, bilbosax <waspenc...@comcast.net> wrote: > > Thanks Erik! I have got things underway and am already seeing > improvements, > but I have a lot more tweaking to do. > > Do you have any idea what the enableQueing function does in the > contentCache? The documentation is a little bit vague > > > > -- > Sent from: http://apache-flex-users.2333346.n4.nabble.com/ > > >
