I'm using ArcGIS Runtime SDK for .Net for a big desktop application, and it's great.
Unfortunately, sometimes the app crashes when loading data on the map using a GraphicsLayer, and there is no way to catch the exception, because it happens in the core of the Runtime.
I've used the SDK since the beta, and at the time, I thought the few crashes would be resolved by the time the final version would come out. Besides, I couldn't reproduce the problem easily, as it happened quite randomly.
But the problem is still there somewhere, and the more data we load on the map, the more quickly it crashes. This is becoming a major issue for us...
Today, I'm finally able to provide a sample app reproducing the problem, and I would like to report a bug so that you can fix it, hopefully.
After looking for a bug-report platform for an hour, I could not find a better place than here to do that ( ! ), so please point me in the right direction if I'm mistaken.
Anyway, please find the sample project demonstrating the crash attached to this message.
The is the right place to report your bugs - unless you have paid-for support in which case you also have the option of contacting technical support. Thanks for the repro - it's great to have such a focussed app which we can use to repro the issue in house.
Is the test dataset a realistic representation of what you are trying do with graphics layers? This type of data (large number of features with complex geometries) should definitely be using the Static rendering mode and you should either be adding via the GraphicsSource property or use the AddRange method. If added in this way, with the app running in either x86 or x64 I see no problem.
However, I did see a crash when using the dynamic rendering mode and running as x86. Running as x64 did not exhibit a crash but i did see a possible rendering issue.
I have entered an issue for further investigation - but my advice for your scenario is to use the Static RenderingMode and always add multiple graphics as a batch operation via the AddRange method on the Graphics collection property or using the GraphicsSource property on the layer.
Thanks for your reply.
The dataset is realistic for our use case, but unlike the test project, scale ranges are used to restrict the number of geometries visible on screen.
Using the Static rendering mode seems like the way to go, but previous tests with this mode have shown a big loss of performance because we were adding Graphics as is, without batching. Using the GraphicsSource is out of question since we are constantly adding new Graphics, but I'll follow your advice and investigate to see if there is a way to use the AddRange method appropriately.