Changing GraphicsOverlay randomly causes freezing

08-19-2020 12:06 PM
New Contributor II

We have a WPF application using v100.6 of the ArcGIS .NET SDK.

Marker symbols are added to the map and their location and appearance are updated by ongoing DIS traffic.

We have found since September last year that the thread updating the MapView would occasionally freeze when trying to remove a Graphic to replace it with an updated one.

In an effort to fix this I have changed the code to just update the position and symbol of the graphic rather than recreating it, but this just caused the same thing to happen when setting the Symbol property on the Graphic. Currently the symbol is still recreated quite a lot, so if that sounds like a potential reason to cause this I can try just updating the composite symbol rotations instead.

Initially, the GraphicsOverlay was updated by methods originating on different threads, and when it froze it meant only the map control would freeze, but I have since changed the application to marshal events from background threads onto the dispatcher (UI) thread as is suggested in the best practices guide, but all this achieved is freezing the entire application rather than just the map.

So in summary, I have tried to eliminate being on the wrong thread, deadlocks within our code and excessive object creation, but there has been no improvement (in fact in some cases it is worse).

There is no exception, CPU and memory usage are low and I cannot see the stack trace into the native code to give any more hints except that it usually ends at CoreVector within the SDK C# code.

Unfortunately I am unable to share any source code, but I am hoping as similar things have been reported over the last 6 years that there is a known cause and solution to this kind of issue or at least someone can advise me of the best practices to follow when updating the position and symbol of Graphics (considering that the best practice guide I found only mentioned using the dispatcher thread, which has not helped and therefore doesn't seem to be necessary).


0 Kudos
0 Replies