Efficiently Move Polylines

1260
13
06-10-2018 03:32 PM
ScottBrady1
New Contributor

Hi,

I am aware that the MapPoint object has the MoveTo function that allows one to efficiently move points from one location to another without re-creating the object. 

Is there a method or technique that facilitates moving polylines between two locations on each timer tick without incurring the overhead of creating new Polyline objects.

Kind Regards

Scott

0 Kudos
13 Replies
ScottBrady1
New Contributor

Forgot to mention that its for 10.2.7

0 Kudos
dotMorten_esri
Esri Frequent Contributor

The move operation is a very special-case optimization at the GPU level and only works for points. It gets complicated really quickly for lines and polygons and a similar optimization isn't really possible. There's not really a way around generating a new line or polygon for these scenarios

0 Kudos
ScottBrady1
New Contributor

This is unfortunate news as we are reviewing your product in the hopes that in can sustain a large number of mappoints with interconnecting relationships between other points using polylines. Creating and destroying thousands of polylines per second is an expensive operation in terms of application performance and responsiveness.

0 Kudos
dotMorten_esri
Esri Frequent Contributor

I just modified my flight-tracker sample to also animate lines. It's handling around 8000 points, with about 2-300 updates/second. Animating the points at 60 frames per second + animating a line to each of those points didn't seem like an issue at all.

I'm curious to know what sort of problems you were hitting with this?

0 Kudos
ScottBrady2
New Contributor

Is it possible that i could have access to this modified flight tracker sample?

Kind Regards

Scott

0 Kudos
ScottBrady2
New Contributor

Hi,

Anyone there.

Kind Regards

Scott Brady

0 Kudos
dotMorten_esri
Esri Frequent Contributor

I based it off of this sample: arcgis-runtime-demos-dotnet/src/GeoEventServerSample at master · Esri/arcgis-runtime-demos-dotnet · ... 

However I'm using a different must more intense service that I can't share, and I extended with some line animations. I doubt the example is useful for your scenario - I merely hacked some stuff in quickly just to get a feel for the performance, and it seemed ok.

0 Kudos
ScottBrady2
New Contributor

Hi Morten,

My application is significantly more complex than the demo you provide.

MapPoints are not an issue.

I can add as many points on the map as I like and everything is efficient.

My problem comes when I add maplines to the map.

Each point has a line connecting up to nineteen other points.

Consequently I can have thousands of map objects on the map at any given time updated every second using a timer.

It is only when adding the lines to the map that performance begins to degrade.

Points are handled efficiently as I simply can call the moveto function and not have to recreate them.

The lines on the other hand have to be cleared from the map and recreated on each timer tick.

I have reviewed many products on the market and with this like what I see.

This issue however is integral to our product.

Our requirements are quite demanding and intensive.

Kind Regards

Scott Brady

0 Kudos
dotMorten_esri
Esri Frequent Contributor

The lines on the other hand have to be cleared from the map and recreated on each timer tick.

You don't need to clear them out. You'll just update the geometry property on each graphic.

I had around 200--300 lines updating continuously 60 times per second, and over 8000 lines rendering total (not everything updates every second), and I was able to smoothly pan and zoom around while that was ongoing. Granted I'm on a rather powerful laptop, but for extreme scenarios like this, I think you'd want to run on powerful hardware.

My sample might be useful to you as it tries to really optimize how animation updates are done in bulk on each UI thread update, rather than hammering it on individual timer updates. 

Also one thing to consider: I was using UWP and not WPF. We've found that UWP's .NET Native compiler delivers over twice as fast interop performance over the .NET Framework that WPF uses. While the interop layer normally isn't hit that hard, in these constantly updating features scenarios, you're hitting that interop layer relatively harder, and rendering performance can suffer somewhat from it. Also UWP has a much better composition layer that allows us to more efficiently render DX11 to the screen with much less overhead than WPF can do. UWP does require targeting Windows 10 though.

Also you mentioned 10.2.7 earlier. Have you tried 100.2.1 ? Lots of changes has happened since then, and we spent a lot of time improving WPF rendering performance in 100.2.1, and the upcoming 100.3 will be even better (and getting a lot closer to what UWP can deliver).

0 Kudos