topic Re: Runtime 100.8.0 Degraded Performance in .NET Maps SDK Questions

Runtime 100.8.0 Degraded Performance

RobBever — Wed, 15 Jul 2020 04:49:05 GMT

I have a WPF app in which I have a 2D and a 3D view which I can switch between. My build is 64-bit. I have a bunch of TPKs loaded at startup when my app runs (3 elevation TPKs, ~650MB, 14 map TPKs, ~8GB).

I have this all working with 100.6.0 (toolkit v100.4.0) and it's great. I'm excited about ImageFrame so I updated to 100.8.0 (WPF and toolkit) but I immediately noticed that the performance is noticeably worse. When you go to move or rotate the camera in 3D there's a noticeable delay before it responds and it's just more sluggish all around.

I reverted my code back to 100.6.0 and it definitely has better performance again. I ran them at the same time and I could easily see the difference going back and forth. See attachments, I recorded them, they were both running and I switched between them, hopefully you can see it. I stop the mouse and click and drag; with 100.6.0 the map follows almost 1:1 where the mouse goes, whereas in 100.8.0 there's a .15-.35ish second lag before the map starts tracking the mouse. When I create some graphics the difference gets larger, but it's there before I even draw anything, apparently the maps being loaded is causing the problem by itself.

I'm wondering if having a bunch of TPKs loaded ahead of time is slowing it down, even though the TPKs are mostly not in the viewing area and 100.6.0 didn't have an issue. Any thoughts or ideas? Is there anything I should try doing differently with 100.8.0 to see if it helps?

Re: Runtime 100.8.0 Degraded Performance

dotMorten_esri — Wed, 15 Jul 2020 15:22:26 GMT

Do you see the same problem with no extra data loaded? If not, at what point do you start seeing this degradation?

> I'm wondering if having a bunch of TPKs loaded ahead of time is slowing it down, even though the TPKs are mostly not in the viewing are

More layers definitely will have an effect on performance, but I would have expected that hit to be the same as with 100.6 and not getting worse.

Re: Runtime 100.8.0 Degraded Performance

RobBever — Wed, 15 Jul 2020 15:46:35 GMT

Yes, the hit is still there with no data loaded, just the maps. It's not as pronounced but there's still noticeable delay that wasn't there before. Like I said I ran them at the same time, so it's clear that they performed differently.

Most of the maps were offscreen. I have a couple of big maps, one that covers the whole Earth and one that covers CONUS, and then a bunch of smaller ones.

I just tested removing everything except the big world map, a boundaries map, and a world reference map. I got rid of all the elevation TPKs and just had those three, with the world imagery being ~2GB. It's still noticeably laggy when dragging compared with 100.6.0. It's been totally consistent, 100.8.0 has been laggier in all circumstances thus far. What you saw in the video is pretty much the same with hardly any maps loaded.

I tested with no data, no maps and just the boundaries overlay (covers the whole Earth, ~160MB), and it's still noticeably laggier and the framerate is worse while dragging, although the gap is smaller than it was with more maps and more data. This is for the 3D only, not 2D, although I also have a 2D view that's hidden when I switch to 3D, and I load the same maps and graphics into it.

I don't know if you can see the difference in the video, but you can definitely feel it while interacting with the application. It's not as smooth and you feel a delay before the map starts to follow the mouse dragging.

Re: Runtime 100.8.0 Degraded Performance

RobBever — Wed, 15 Jul 2020 15:53:40 GMT

I didn't mention it but I do not see this behavior in the 2D view. That performs the same in both versions. Dragging or rotating is acting different in 3D but it's the same performance in 2D, I've seen no change there.

Re: Runtime 100.8.0 Degraded Performance

dotMorten_esri — Wed, 15 Jul 2020 21:11:50 GMT

Thanks for that extra info. Just to help narrow things down, do you see the issue in 100.7 as well?

Re: Runtime 100.8.0 Degraded Performance

RobBever — Wed, 15 Jul 2020 23:12:55 GMT

Just tested in 100.7.0. It might be very slightly less responsive than 100.6.0 but it's nearly the same. It's still clear that 100.8.0 is different. I ran them all at the same time with the same set of maps.

I ran them with Task Manager and just zoomed out to a US view in the 3D and dragged the map back and forth, and 100.8.0 peaks a little higher in CPU usage, around 14-15% vs. 8-10% for the other two versions. Memory usage is similar, a bit higher for 100.8.0 (398MB, 408.8MB, 423.1MB). GPU usage similar, peaking around 40-42% for all three versions.

Is running a 2D and 3D view simultaneously (though they're not visible at the same time, only one is visible at a time) and loading everything to both of them the same possibly the culprit? I don't really know what to test for. It's a bit difficult to turn off the 2D view completely but if you think there's a chance that's related I can try it.

Re: Runtime 100.8.0 Degraded Performance

RobBever — Thu, 16 Jul 2020 03:13:47 GMT

I tried removing as much of the 2D stuff as I could. I still add the maps to the Basemap but I stopped the code from adding my usual graphics layers to the 2D view. The result was pretty similar to before. It doesn't seem like that made a significant difference.

One other thing I noticed is that the zooming in and out stutters much more and has a significantly lower framerate in 100.8.0 than in 100.6.0 or 100.7.0 when there's much map data. The code is the same and I add all the same stuff.

Is there anywhere I can look at the frames per second being rendered? That might be helpful to measure what I'm seeing but I don't see anywhere in the API reference where I can get that information.

Thanks for your help.

Re: Runtime 100.8.0 Degraded Performance

MichaelBranscomb — Thu, 16 Jul 2020 12:06:00 GMT

Hi,

A couple of questions:

- Is all your data comprised local file formats + graphics and no remote services at all?

- Do you have any code running on UI events e.g. MouseMove?

Thanks

Mike

Re: Runtime 100.8.0 Degraded Performance

RobBever — Thu, 16 Jul 2020 14:39:23 GMT

Yes, local files and no remote servers, although I added one server:

ArcGISTiledLayer imageryTiledLayer = new ArcGISTiledLayer(new Uri(
"http://services.arcgisonline.com/arcgis/rest/services/World_Imagery/MapServer"));
imageryTiledLayer.Id = "ESRI";
m_esriMapData = new MapLayerData(imageryTiledLayer, MapLayerConfigurationData.Enabled, false);

Sometimes I had it visible and sometimes I had it not visible when I was testing. I think when I don't have it enabled it's not added to the overlays at all.

I do have an event for MouseMove, at least in 2D, but not in 3D. I have a SimpleRenderer that I add to my model graphics overlay when I start up:

private SceneView m_sceneView = null;
public SceneView SceneView
{
get => m_sceneView;
set
{

ModelGraphicsOverlay = new GraphicsOverlay()
{
RenderingMode = GraphicsRenderingMode.Dynamic,
SceneProperties = new LayerSceneProperties() { SurfacePlacement = SurfacePlacement.Absolute }
};

SimpleRenderer renderer = new SimpleRenderer();
renderer.SceneProperties.HeadingExpression = "[Heading]";
renderer.SceneProperties.PitchExpression = "[Pitch]";
renderer.SceneProperties.RollExpression = "[Roll]";

ModelGraphicsOverlay.Renderer = renderer;
ModelGraphicsOverlay.LabelsEnabled = true;

ModelGraphicsOverlay.SceneProperties.SurfacePlacement = SurfacePlacement.Relative;

m_sceneView = value;

SceneView.GraphicsOverlays.Add(ModelGraphicsOverlay);

foreach (GraphicsOverlay graphicsOverlay in m_newGraphicsOverlayCollection)
{
SceneView.GraphicsOverlays.Add(graphicsOverlay);
}

m_newGraphicsOverlayCollection.Clear();

//AttributeLabelClass ac = new AttributeLabelClass();
//ac.TextExpression = "[Label]";
//ac.Symbol = new TextSymbol();
//ac.Symbol.Font = new SymbolFont("Segoe UI", 18.0, SymbolFontStyle.Normal, SymbolTextDecoration.None, SymbolFontWeight.Bold);
//ac.Symbol.Color = Colors.White;
//ac.LabelPlacement = LabelPlacement.PointAboveCenter;
//ac.LabelPosition = LabelPosition.FixedPositionWithOverlaps;
//ac.LabelPriority = LabelPriority.Automatic;

//ModelGraphicsOverlay.Labeling.LabelClasses.Add(ac);

SceneView.SelectionProperties.Color = System.Drawing.Color.Yellow;

EventAggregator.GetEvent<SceneViewInitializedEvent>().Publish(true);
}
}

There's this and then I add a bunch of TPKs to the Basemap, and that's about all it's doing.

I guess I'll try not adding the overlay with the SimpleRenderer and see if that does anything.

Re: Runtime 100.8.0 Degraded Performance

RobBever — Thu, 16 Jul 2020 15:11:51 GMT

I removed the server connection stuff and I took out all the graphics layers I was adding to the SceneView. Now it's just the map alone, local TPKs only, and it still hitches more and scrolls less smoothly than 100.6.0 or 100.7.0. I tried removing most of the maps, just the 2GB world map and the boundaries map (~160MB) and I still see that behavior.

I found out that Windows 10 has framerate benchmarking built in now. I ran 100.7.0 and just zoomed in and out so the map was continuously moving. The framerate for 100.7.0 was 35-53, usually between 40-45. Framerate for 100.8.0 was 20-25, consistently in that range. CPU usage was similar, although it was lower more often for 100.7.0. It seemed like 100.7.0 had higher peak CPU usage but lower average (maybe averaging 25-30%, peak 53%), whereas 100.8.0 used more consistently (30-45%) but didn't peak as high.

So I believe the issue I'm seeing is that difference in framerate. You could try measuring on your side with some local TPKs and scrolling, maybe you can see the issue as well, or maybe it has to do with my GPU, I don't know. If you hit Windows Key + G, you get this Xbox menu, and there's a little bar that has a button marked Performance. If you have your window selected, then you do Windows+G, then click performance, it'll start running a frame counter on the window you had selected when you brought it up.

Re: Runtime 100.8.0 Degraded Performance

RobBever — Thu, 16 Jul 2020 15:18:06 GMT

I put the absolute minimum of maps, just a reference overlay to show where state lines and country borders are, and I did my zooming in and out test again with the benchmarking. With 100.7.0 the FPS was 50-60, averaging around 56. With 100.8.0 it was 35-48, averaging 43. So it seems like this framerate drop is there all the time, no matter how little map data I load.

Note that in the versions other than 100.8.0 I just left my usual setup, so they have lots of graphics layers loaded whereas the 100.8.0 version has nothing but the basemaps. So all else being equal the 100.8.0 should be the fastest.

Re: Runtime 100.8.0 Degraded Performance

RobBever — Thu, 16 Jul 2020 15:28:57 GMT

I went back and turned everything back on, all my layers, maps, models and graphics, so I could benchmark that.

In 100.6.0 the framerate with my aircraft model flying around with other graphics displayed and using the ESRI server imagery and terrain was averaging 45 FPS. In 100.8.0 the same scenario was getting 10-11 FPS. So the difference gets much bigger the more stuff is loaded.

Re: Runtime 100.8.0 Degraded Performance

RobBever — Fri, 17 Jul 2020 06:08:26 GMT

I went ahead and pulled the latest ArcGIS Runtime samples code from git. I tested the latest commit in master vs. the last 100.7.0 version, running the first 3D test I saw, Surface Placement. I ran the same test as before, continuously using the scroll wheel to make sure the Scene View was always zooming in or out.

Framerate for the latest commit in master (107410240da582d59eda0362e27a2a948d7ec999) averaged ~20, min 18, max 26. Framerate for 100.7.0 (commit b7c85930edd7fd6255a2523df5b827c95d9faa2d) was 55-60.

So this problem appears to have nothing to do with my code, I was able to reproduce it right away in the sample app.

Is there any information about my hardware that you think would help you with this? Is this repeatable on your end if you test the framerate of 100.7.0 vs. 100.8.0 or do you think this has something to do with my system?

Next I'll try copying the sample viewer to another machine and see if the problem is the same on different hardware. This machine is a reasonably powerful laptop, I'll try on a desktop next.

Re: Runtime 100.8.0 Degraded Performance

RobBever — Fri, 17 Jul 2020 06:11:57 GMT

I built release x64, although I also saw it on debug Any. So it didn't seem to be related to the specific build type.

Graphics card on this laptop is Intel UHD Graphics 630 with 1GB of video RAM. I'll update with results from the desktop when I get a chance to test on there.

Re: Runtime 100.8.0 Degraded Performance

RobBever — Fri, 17 Jul 2020 06:37:21 GMT

Ran on a desktop, ran the same sample Scene View as mentioned previously, I copied the Release x64 builds of 100.7.0 and 100.8.0 to this machine.

With 100.7.0 it ran 50-60fps, averaging around 55. With 100.8.0 it ran mostly 40-50fps, averaging around 45. So the difference is still there, it just gets more pronounced with more stuff being displayed, and it diverges a lot by the time I have models and layers and draped shapes and such.

Graphics hardware is Intel HD Graphics 630 with 1GB of video RAM.

I'm less concerned about this specific version, obviously I can just not upgrade for now, but whatever's causing this framerate drop will probably carry forward until it's caught. I wonder if you can reproduce this using the same methods I've used or if it's only happening for me.

Re: Runtime 100.8.0 Degraded Performance

RobBever — Fri, 17 Jul 2020 06:51:20 GMT

Tried updating to the latest drivers for the graphics hardware on the laptop. Results were the same for the sample application as before.

Re: Runtime 100.8.0 Degraded Performance

dotMorten_esri — Fri, 17 Jul 2020 17:00:12 GMT

Thank you for all this testing and the details. This is helpful.
I'm curious how you're testing the framerate? There were a few changes that could affect these metrics and not give you the right number (WPF can be a little weird in that respect). However I'm assuming that besides measuring, you are visually seeing a significant difference?

Also are you seeing the same behavior with panning, and not just mouse-wheel zooming?

Re: Runtime 100.8.0 Degraded Performance

RobBever — Fri, 17 Jul 2020 17:18:16 GMT

I described my method above. Windows 10 has added Xbox Game Bar (or you can install it for free via the Windows Store), which has a framerate counter for a selected window/application (I'm not sure if it's by window or by application, but my app and the sample viewer only had one window in my tests anyway).

Its measurements lined up closely with my perception. I saw the lower framerate (that's what I was trying to convey with the videos) and the measurements made perfect sense with what I was seeing.

The behavior was pretty much the same with panning and rotating, but it was easier to keep the camera in motion continuously with zooming because of the smooth zooming in and out behavior when you scroll the scroll wheel. Zooming, panning and rotating seemed to behave similarly, with 100.8.0 having a lower framerate in all situations.

I was mostly using the framerate counter to quantify the different behavior. It seemed very accurate, it at least lined up with how it looked to me. If anyone could do WPF framerates right, you'd think Microsoft could, although I'm sure it's not perfect.

Re: Runtime 100.8.0 Degraded Performance

RobBever — Fri, 17 Jul 2020 17:32:47 GMT

I found a more complex example from your sample application. I'd like to attach videos of the Line of Sight example, but I can't get the video uploader to work. Is attaching things different now? It seems different than when I uploaded the other files just a day or two ago, I didn't have to deal with that video uploader, and I can't get it to work.

Video Links here:

Dropbox - Line of Sight Demo 100.7.0.mp4 - Simplify your life

Dropbox - Line of Sight Demo 100.8.0.mp4 - Simplify your life

In both videos, I move the mouse to a point, stop, then click and drag. There's a lot of delay in the 100.8.0 version, presumably because of the low framerate. You can see how much slower it updates in the video in this case.

Since there's a lot of geometry in the scene, you can see the difference in framerate much more clearly here. Version 100.8.0 just renders the Scene View way slower, and the difference gets bigger the more complex the scene is.

Re: Runtime 100.8.0 Degraded Performance

dotMorten_esri — Fri, 17 Jul 2020 18:24:23 GMT

Thank you! All this info is very helpful. The new videos definitely shows it clearer.