Runtime 100.8.0 Degraded Performance

[RobBever]

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?

[RobBever]

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.

[RobBever]

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.

[RobBever]

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.

[RobBever]

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.

[RobBever]

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.

[RobBever]

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

[dotMorten_esri]

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?

[RobBever]

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.

[RobBever]

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.

[dotMorten_esri]

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