This is a good request @yxztj ! We'd also use such an API from AsyncDisplayKit, since it sets priorities depending on how close an image is to the screen. When a new screen loads, often there are downloads started for the Visible area, the "almost-visible" area, and the preloading area - and it would be great to be able to pass those priorities in without a separate call.

Have you been able to test whether this makes a difference on how the network requests go out? There is additional overhead to the extra calls - but, does the network request start immediately or does it wait long enough that the priority calls are able to influence how the initial set of connection slots are allocated?

On Oct 27, 2016, at 2:16 AM, yxztj notifications@github.com wrote:

Currently it's not possible to set task priority when calling downloadImageWithUrl. Can we add another parameter for priority in the API, instead of setting it separately after creating the download task?

Background: We have a long tableView with lots of images, each cell contains random static image or gif image(also load it's first frame as placeholder. gif task priority is changed dynamically based on cell's state and is always lower than static images). When scrolling fast usually there would be a lot of concurrent tasks in manager's _concurrentOperationQueue. Currently changing priority would add another operation to the queue and enumerate all running tasks to find the specified download task, which takes time.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub #262, or mute the thread https://github.com/notifications/unsubscribe-auth/AAigA7A7Ni2i581eY9tXnDzm_7CWBLtlks5q4GvbgaJpZM4KiHgq.

@appleguy Yeah I've been using ASDK to set image download priority based on node's interface state(preload, display, visible). We're using FLAnimatedImage and some other image processing so we implemented ASImageCacheProtocol/ASImageDownloaderProtocol on our own web image manager, which relies on PINRemoteImage.

We're logging the _urlSessionTaskQueue operations' priority on each setPriority call. But not seeing the queuePriority property changing right after(guess the set operation is also queued in _concurrentOperationQueue) So maybe setting the initial priority on downloadImageWithUrl could reduce some work?

In addition since NSOperationQueue doesn't guarantee operation with higher priority gets executed first, when we check the network requests using Charles, not seeing much performance advantage after setting download priority dynamically.. Sorry we haven't digged deep into the whole library, could be still missing something.