ArcGIS JavaScript API Cancel tile fetches

[RyanSutcliffe]

This is a general question. We've noticed that scroll zooming in our ArcGIS JavaScript API 4x maps is a major pain point for performance. The problem is that zooming from a zoom level of say, 5 to 17 will go through all scales in between: 6,7,8,9,10... and so on.

Even though the user passes through the scale almost instantly, the fetch for the tile at each of these scales is queued up and the browser must wait for all these intermediate layers to be fetched from the server before it will load the data the user actually wants at scale 17. 

This causes problems for both the browser and our servers. Most browsers limit concurrent network requests so our apps can become slowed because of a large backlog of queued requests that must be processed. It also causes undue strain on the server trying to serve many requests.

The behaviour I would like to see is to have the browser/API somehow be able to cancel fetches if they're no longer needed because the user is not at that scale or view extent and/or an ability to prioritize fetches for data at the scale view extent the user is currently at.

I read some forums that suggested the Google Earth API had some functionality that handled this as well as with Leaflet however I did not confirm or test.

I would like to know if the API has any tools or ability to improve such a use case and what the recommended approach would be from ESRI to handle such a scenario. 

Unfortunately I cannot provide much in the way of samples as our site is not public. In order to reproduce, you would load an ArcGIS JS API map with cached tiled raster or vector data, look at the network pane in the developer tools and observe the network traffic as you zoom in or out via continual scrolling. Note how fetches are made at every zoom level in the network pane. 

Update/correction: above behaviour tested extensively on API v. 4.15 but observed in 4.15-4.18. Correction: behaviour is also specific to ImageryTileLayers (see below)

[mgeorge]

Hi @RyanSutcliffe, are you referring to FeatureLayers? Requests should be getting canceled as you zoom in. If you go from LOD 1 -> 10, you should see 2-9 get canceled in the network tab. What version of the API are you using?

[RyanSutcliffe]

I've primarily observed this behaviour with cached Raster services: served as imageryLayer or imageryTileLayer in ArcGIS JavaScript API and provided from ImageServices from ArcGIS Server. I just checked and we don't have any cached featureLayers in our app at the moment. But I would still be interested if you have any links, docs, or can link a video showing this cancel of requests working in the network tab, even if it is only for featureLayers.

[mgeorge]

Hmm, if you take a look at https://developers.arcgis.com/javascript/latest/sample-code/sandbox/index.html?sample=visualization-... I can see requests being canceled both for VectorTileLayers (the basemap in this case) and FeatureLayers (the dot density layer):

If I switch the basemap to an TileLayer (non-vector) I can also see cancellation:

For an ImageryTileLayer though I think I see what you are talking about. Some requests do still get cancelled, but it looks like less requests are getting cancelled than should be.

Imagery tile layer does a lot of processing on the client and is quite expensive at the moment... I imagine what's happening here is the processing is blocked on something which might be causing requests not to get cancelled when they should. It could also be that the abort controlled isn't hooked up properly for this layer type. I'll make an internal issue to see if we see what's going on here.

[RyanSutcliffe]

Thanks for your investigation. I want to correct my statement above, that you are right, the behavior is specific to ImageryTileLayers and that is where we've observed this issue.

In cases where I've been observing this behavior we have been using ArcGIS JavaScript API 4.15. I just did some testing using ArcGIS JavaScript "next" for latest-greatest and see behavior is the same (as you describe above). Using this code pen as a sample, if I zoom in via scroll quickly into a scale of 1:4000 or larger, where the layer is turned off, I can observe that usually none or very few of the ~250 tile requests queued up get cancelled. (Chrome/FF). Because this sample dataset is pretty small I throttle the network via network tools to make the behavior more noticeable.

Will be interested to hear what you find out. If an internal ticket is created, is it possible we can receive update notifications via our ESRI Support account?

[mgeorge]

Hi Ryan -- I was looking at this with another dev yesterday, and thanks for bringing this to our attention! We might still be able to get some fixes in for 4.19, and we'll have more for 4.20. There's also potentially some low hanging fruit in terms of optimizations that we can do to improve the frame-rate for these layer types (a huge cost right now is the amount of per-pixel ops that we need to do to prepare the data for these layers)

Unfortunately there's not a great way to get notifications, though I can reply to this thread with updates. You can also open a support ticket, and then we can get that mapped to the dev issue.

[RyanSutcliffe]

We've recently tested this behavior at the recently released 4.19 version and noticed things seem to be much improved for ImageryTileLayers in the app after some quick tests. Although its not mentioned in the release notes, we're seeing as much as 70% less data transferred in a typical zoom scenario test compared to 4.15 and a noticeable draw speed improvement. Opening the network pane we can see the majority of data in the intermediate zoom layers are being cancelled. @mgeorge if you're able to confirm this I can mark this ticket as answered and solved. 

[mgeorge · Accepted solution]

Great! Thanks for checking back Ryan. We did merge a couple of fixes late in the release, glad to see things are significantly better for you.

We have a few additional ideas on further improving ImageryTileLayers performance, hopefully we can start tackling those in the upcoming releases.