ArcGIS Runtime 100.4 draws basemap really slow when zooming with the mouse wheel

437
4
12-07-2018 05:18 AM
Highlighted
New Contributor III

I've created an application for in Visual Studio 2017.Net  WPF and with ArcGIS Runtime 100.4 just using the standard application when you create a new project.

I thought the usage of tiled cache should be fast, but using ArcGIS Runtime .Net 100.4.

When I zoom in and out with the mouse wheel it some times take about 4-20 seconds before all the tiles for the extent is loaded. 20 seconds! is really slow. In the Javascript API it is no wait time near this at all. I have 8 GB Mem. 4 core cpu, NVIDIA Quadro K2100M GPU. Anyone experience this? It seems to be loading a lot of tiles. As it sends request for every step I reach during the wheel zoom operation. Shouldn't there be an cancellation of previous requests that doesn't count any more since the extent has changed? There is also the animation on between the zoom levels that slow the zooming process down as well. It should be able to urn this off or at least adjust the time of the animation.

See attached video!

4 Replies
Highlighted
New Contributor

Are you in Debug and seeing lots of Task Canceled exceptions in the output window?  If so this is something that they are aware of and generates this question frequently as it did with me.

See this thread:

A lot of web exceptions at runtime even in arcgis-runtime-samples-dotnet-master project 

Reply
0 Kudos
Highlighted
New Contributor III

Hi Bryan,

Did a test. Same behavior when running as a released EXE file. Slow.

Reply
0 Kudos
Highlighted
Occasional Contributor II

Same problem here, with or without debugger, however I have no resolution. Based on my observations, I have two theories:

  1. Animation stutter is allowing tiles for each wheel delta/zoom level to complete loading or delay cancellation
  2. Tiles are not really cancelled

Or a combination of the two. The post Bryan Roth refers to suggest they are indeed cancelled, but perhaps delayed or interfere with the overall performance?

CPU usage is also quite high during the zoom operation. Previous attempt with CPU profiler (RedGate) points to the animation (at least in pre 100.2), though it is hard to say if these things are related. Another vote for disabling and/or controlling zoom duration for MapView and SceneView

Highlighted
Occasional Contributor II

I just did some minor testing in a small application with one map using ArcGIS Runtime for .NET WPF, and another using ArcGIS Runtime for WPF. Both maps are 500x500 pixels. Since I currently only have a track pad, and and that doesn't do well with gesture zoom, I arm myself with my maps, Fiddler and rectangular select.

ArcGIS Runtime SDK for .NET:

Trying a rather small rectangular select zoom, starting at LoD 3 to 8, tiles from lod 4, 5,6,7 and 8 are loaded during the operation, resulting in a total of 54 tiles.

Going from level 8 to 14, 66 tiles are loaded from LoD 9-14 (10 is skipped, and never requested). 25 tiles are loaded for level 14.

ArGIS Runtime for WPF API:

Doing the same sort of operation in ArcGIS Runtime for WPF API, going from level 7 to 12, only 9 tiles are loaded from level 12. 

The newer runtime loads tiles for each zoom level it traverses on the way to the target level, without cancelling any of the tiles from the skipped levels, and in addition download a lot more tiles that are not displayed. If the MapServer of the layer is slow, this results in a very poor user experience. If using multiple basemaps are visible (i.e basic maps blended with Opacity against areal photo), this makes the experience even worse.

The old runtime performs pretty well, even if the map server providing tiles is slow. Tiles load slowly, but the zoom operation itself is not impacted, and only the tiles required are loaded.

My MapView is only 500x500px, but from just LoD 14, 25 tiles are loaded in the new runtime. Why does it insist on downloading that many tiles for the level, in addition to requesting tiles for levels that are not displayed?

I realize that in 100.x, everything is async, but I would still assume that the number of tiles must have an impact on both CPU and user experience.

There are no request cancellations related to this zoom operation, even if i disable Just My Code. The Cancellation/WebExceptions/ObjectDisposed will occur if I double click many times to zoom in, but do not occur even once for this experiment.