Here's another idea. It's logical to assume if using non-virtual List, that when the dataProvider is assigned to an ArrayCollection that the collection order (natural, or ordered if you set a Sort in an extended collection) is also the order the ItemRenderers will indeed start rendering in the order of the collection because the view needs to add each UI element to the UI container in the visual order. I see no logical reason why Flex creators would create the elements in an order other than visual order since that's all a List does is add elements to a parent container ordered the same as the underlying dataProvider.
It's the asynchronous GET calls that makes it appear there is some order in which they are called as they render in parallel. So here's my idea. Use a ContentCache and set maxActiveRequests to the number of images that will be visible for the given device or screen. If the ItemRenderers are being rendered in the underlying collection order (I bet they are) it will not ask for more images until the first GET completes so your first visible items will always render first and you'll limit the number of parallel GET calls to minimize bandwidth used at once. This might help. Erik On Oct 11, 2017, at 11:12 AM, Erik J. Thomas <e...@linqto.com> wrote: Despite the fact that a non-virtual List or DataGroup will attempt to render all ItemRenderer instances by iterating the dataProvider in some sequential order, the speed at which the images appear is only influenced very little by the order the instances are rendered. This is because as each renderer is laying out, the moment the Image.source is set to a URL, it's Loader will make an asynchronous HTTP GET request for the image bytes. The UI thread does not wait on the image to show up to complete laying out the renderer. Essentially the time it takes for each renderer to layout while the images are waiting on async responses happens so quickly, the speed at which the images appear will seem almost random based on the asynchronous nature of the HTTP GET calls. It's highly likely that all the Image.loader GET calls will have fired before the first image's response is received. The size of the response payload (size of the image byte array) will influence to how quickly a given HTTP response is received as well. But practically speaking, all image requests are happening very nearly in parallel for the entire list, meaning you are slowing down how fast images will appear because your internet bandwidth is being utilized for all images at once. If you use List with virtualization set to true, the number of image loader requests will be reduced to the visible renderers in the viewport (plus some number of buffered renderers for better scrolling performance). So the initial display of the visible images will be faster with virtualized List since you're not receiving so may image byte arrays at the same time. If you were able to force the order of the requests, it should make very little difference in how fast the images render because all HTTP requests are happening in parallel. Your only solution is to preload a ContentCache with images before displaying your list using your own Loader, OR, don't load offscreen images until your onscreen images have loaded. You can't do this with data binding using a List and dataProvider, except to set the List to use virtualized item renderers. Again, List performance optimization was a high priority for Adobe (and Apache) developers and I doubt you are going to improve this much if at all. Another idea is to use DataGroup or non-virtual List and set the dataProvider before the user views the list (includeInLayout true, but visible false) so it is collecting and caching all the image bytes in the background before your view is visible, then when the user navigates to the view with the list, all images will already have been loaded (HTTP Get requests for all images have completed) and then they simply have to render. Erik On Oct 11, 2017, at 9:17 AM, Alex Harui <aha...@adobe.com.INVALID> wrote: I don't know enough about the layers of the internet to answer your question, but a network monitor can help show why things are happening the way you describe them, and then you will have more data to use to form a solution/workaround. Right now, all we have is speculation. Think of it this way: if you create an HTML page with 20 <img> tags, will the images pop in in the same order every time (assuming you've flushed the browser cache beforehand)? I don't know the answer, maybe someone else does. And the server might be serving those images in an unexpected order and maybe there is a way to correct that. Pre-loading the images as someone else suggested should help. You could also try to coordinate between renderers and only have one renderer make an image request and queue the others until the first one comes back. HTH, -Alex On 10/11/17, 6:39 AM, "bilbosax" <waspenc...@comcast.net> wrote: > I hear your logic, but I'm not sure that I follow. I make a database > request > that downloads a bunch of url strings to an array collection that are in > the > order that I want them displayed and the priority that I want them > rendered. > After the arraycollection is populated, a component is instantiated > containing the list and the array collection is set as the data provider > and > the images begin to render. The problem is that it seems that the first > three images that are initially on the screen are the LAST to be loading. > If > the data provider is being set all at once, you are telling me there is no > way to force the render order from 1 to 24 instead of 24 to 1? > > It sounds like you are saying whoever gets their data first will render > first, but if I just hand off the data provider, I can't control who will > have their photo delivered first so it will always be random. Is that > right? > > > > -- > Sent from: > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fle > x-users.2333346.n4.nabble.com%2F&data=02%7C01%7C%7Cd0797f4884ac4a5f1fef08d > 510ad7591%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636433259549007197& > sdata=THUXvhnsmFF%2F3FpxTl%2B6eHIPry%2Fjaij96M2VdfoDDx4%3D&reserved=0
