Performance Questions

[MarkCollins]

I have a couple quick questions I was hoping you could help me with in regards to performance of the ESRI WPF control.  A bit of background about our project: Our application displays the real time location of calls for service and vehicles from several dispatch center systems.

We are currently stress testing our application with a concurrent load of 2000 vehicles and 150 calls and are experiencing performance issues with the map. We would like to able to target even higher numbers in the future.

My questions are as follows

1. Is there a maximum recommended number of items to display on the map at a time? Is it insane to attempt to render 2000+ items on the map at one time? We are using a GraphicsLayer and MarkerSymbols w/ a custom control template. We are also using custom clustering logic which seems to help when turned on.
2. Is there possibly a better performing way to render our points w/ custom symbology?
3. Do you have any best practices or tips for getting the best performance from the map control?
4. What tools / metrics can be used for monitoring and analyzing map performance? We have been using the VS 2010 performance explorer and the Red Gate profiler on our entire app. Are there any specific tools / approaches you can recommend?

[DavidLednik]

Hi Mark,

Depends how your workflow is set up.
I would suggest you check out how the sample application "Moving Graphic Objects" is designed. Should be something similar to your
case. It is found under Mapping > Graphic Layers.

It works ok even with 10000 objects.

Regards,
David

[AaronHigh]

The moving graphics sample won't be valid for his use case, as he states,

We are using a GraphicsLayer and MarkerSymbols w/ a custom control template. We are also using custom clustering logic which seems to help when turned on.

These features are not compatible with the AcceleratedDisplay (which that sample uses).

[AnttiKajanus1]

The issue here is that WPF graphics rendering pipeline cant cope with too much information on the screen. And theres not much we can do about it than not use things that that uses that. This leads us to why AcceleratedDisplay (or should I say DirectX rendering pipeline was developed in the first place) and using that.

How I see things going is something like this :

1) Use accelerated layers and if you can, put all your stuff there
2) Use accelerated layers when ever you can and when you really need WPF rendering, transfer graphics to graphicslayer that is living outside of Accelerated layers. If you want do this approach you might be interested a way how you can define both AcceleratedSymbol and CustomTemplate to one Renderer (http://kajanus.net/?p=132, it seems that I have forgotten to upload code to GitHub)
3) Create Images on the fly to achieve same visualization that you are looking after to be able to use PictureMarkers in the AcceleratedDisplay
4) Think another ways to reduce graphics (and their complexity) on the screen, ie. providing multiple services from the same data that visualizes things differently depending on the scale and switch those in code...

As a bottom line, always take advantage of AcceleratedDisplay when you can and that should be your target. Since we are now discussing about existing implementation, see if you can adapt to use it as a default or use it partly.