The application remains responsive and does not die. The map view, however, stops accepting user input and appears frozen. We've seen this sporadically. Below is a small sample that reproduces the problem. Note you may have to run it a few times before it occurs; the issue does not happen every time.
<Window
x:Class="Sample.MainWindow"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:esri="http://schemas.esri.com/arcgis/runtime/2013"
Title="esri sample" Height="350" Width="525">
<Grid>
<esri:MapView x:Name="MyMapView">
<esri:Map x:Name="TheMap">
<esri:ArcGISTiledMapServiceLayer
ServiceUri="http://services.arcgisonline.com/ArcGIS/rest/services/Ocean_Basemap/MapServer" />
</esri:Map>
</esri:MapView>
</Grid>
</Window>
using Esri.ArcGISRuntime.Geometry;
using Esri.ArcGISRuntime.Hydrographic;
using System.Collections.Generic;
using System.Windows;
namespace Sample
{
/// <summary>
/// Interaction logic for MainWindow.xaml
/// </summary>
public partial class MainWindow : Window
{
public MainWindow()
{
InitializeComponent();
var center = (MapPoint)GeometryEngine.Project(new MapPoint(-80.1, 26.1, SpatialReferences.Wgs84), SpatialReferences.WebMercator);
MyMapView.SetView(center, 30000);
SingleMapRepeat();
//MultiMapRepeat();
}
private void SingleMapRepeat()
{
//Wait for the zoomed area, most likely to see frozen. If not, increase the repeat number.
int repeat = 9;
MyMapView.LayerLoaded += Zoom;
AddS57("../../../../../../s57/US5FL32M/ENC_ROOT/US5FL32M/US5FL32M.000", repeat);
}
private void MultiMapRepeat()
{
//start to see frozen when repeat is 3. If not, increase the repeat number. Pan or manually zoom may increase the chance to make the map frozen.
int repeat = 3;
MyMapView.LayerLoaded += Zoom;
AddS57("../../../../../../s57/US5FL32M/ENC_ROOT/US5FL32M/US5FL32M.000", repeat);
AddS57("../../../../../../s57/US4MA23M/ENC_ROOT/US4MA23M/US4MA23M.000", repeat);
AddS57("../../../../../../s57/US3NY01M/ENC_ROOT/US3NY01M/US3NY01M.000", repeat);
AddS57("../../../../../../s57/US1GC09M/US1GC09M.000", repeat);
AddS57("../../../../../../s57/US2EC01M/US2EC01M.000", repeat);
AddS57("../../../../../../s57/US3FL30M/US3FL30M.000", repeat);
AddS57("../../../../../../s57/US4AL12M/US4AL12M.000", repeat);
AddS57("../../../../../../s57/US5FL4AM/US5FL4AM.000", repeat);
AddS57("../../../../../../s57/US5AL12M/US5AL12M.000", repeat);
}
private void AddS57(string path, int repeat)
{
for (int i = 0; i < repeat; i++)
{
var layer = new HydrographicS57Layer() { Path = path };
layer.DisplayName = path;
TheMap.Layers.Add(layer);
System.Console.WriteLine("add layer " + layer.DisplayName);
}
}
async void Zoom(object _, Esri.ArcGISRuntime.Controls.LayerLoadedEventArgs e)
{
System.Console.WriteLine("zoom layer " + e.Layer.ID + " " + e.Layer.FullExtent.Extent.XMin + " " + e.Layer.FullExtent.Extent.YMin);
await MyMapView.LayersLoadedAsync(new Esri.ArcGISRuntime.Layers.Layer[] { e.Layer });
await MyMapView.SetViewAsync(e.Layer.FullExtent);
}
}
}
Hi,
I think it's just the case that each ENC file takes a little time to process, and that processing (and perhaps the subsequent rendering too) is fairly CPU intensive. The way in which you're adding multiple copies of the same file to the Map would appear to give the impression that the MapView has stopped responding when in fact as far as i can tell from my testing the MapView is alive and well but working hard.
It may depend on your scenario, but if possible a better approach would be to load only the file(s) you need for your current MapView extent?
Cheers
Mike
Thanks for the quick response, Mike.
In our actual code we filter duplicates. We've also now limited the max number of S57s to 9 and prevented removing of the layers until they are loaded in order to reduce (but not eliminate) the chances of the problem. The sample posted code was a small example that reproduces the sporadic freezes we've seen of the map view. We've noticed the map view freeze when zooming to an S57 layer's extent and more rarely when trying to remove a layer. Since it is so sporadic, our only speculation at this time is a concurrency/timing hazard in the runtime (unless we are using the APIs wrong unknowingly?).
When the runtime freezes, it might as well be dead from the user's perspective. No interaction (pan, zoom) is possible with the map. In this attached screenshot, the map has been unresponsive for more than 5 minutes. The black is from the outline of an S57 layer. It died while zooming in and got frozen when the black part of the outline was on screen.
I've also gotten the app to actually crash.
Technique to help reproduce: scroll the mouse scroll wheel back and forth like a maniac while the S57s are loading. Yes, this is not normal user behavior, but it helps trigger the issue which happens rarely otherwise and is hard to track down.
quick update: 10 minutes, still frozen. It's dead.
Once the runtime enters this bad state, it is then possible to freeze the entire application: Occasional hangs in the runtime
Our tests show that it is most likely to occur when there are multiple zoom operations in flight. Also, it is more likely when running on a lower powered or otherwise burdened computer. That sounds like a concurrency bug: the operations on a slower computer take longer to complete and increase the chances of revealing the unhappy collision/overlap.
I have the same problem with this in runtime .net 10.2.7. Have you got the solution ?
This is a known bug in 10.2.x. I could not find any solution for this.
In 100.2 ENC will be supported, hopefully without this problem.
Thank you so much for reply. I hope ENC will be supported in basic level
like arcgis 10.2.x
regards
erwin
100.2 is now available, and there's an ENC sample here:
https://github.com/Esri/arcgis-runtime-demos-dotnet/tree/master/src/HydrographicsSample