nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

runtime freezes sometimes when zooming on S57 layer -- bug or incorrect api usage?

carloscasanova

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);

}

Encontre mais publicações marcadas com

Accepted answers

All comments

SomeGISGuy

100.2 is now available, and there's an ENC sample here:
https://github.com/Esri/arcgis-runtime-demos-dotnet/tree/master/src/HydrographicsSample

amiamijaya

Thank you so much for reply. I hope ENC will be supported in basic level

like arcgis 10.2.x

regards

erwin

MaxGlas

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.

amiamijaya

I have the same problem with this in runtime .net 10.2.7. Have you got the solution ?

carloscasanova

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.

carloscasanova

quick update: 10 minutes, still frozen. It's dead.

carloscasanova

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.

MichaelBranscomb

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

Participe da Conversa

Membros conectados podem postar, seguir atualizações e mais. Novo aqui? Registre uma conta gratuita.

Links Rápidos

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.