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.
See attached video!
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:
Same problem here, with or without debugger, however I have no resolution. Based on my observations, I have two theories:
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
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.