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]

You were able to see the videos, good. Do you see any difference in performance on your end with this test? Or does the Line of Sight example perform the same as 100.7.0 for you?

You may need to try it with weaker graphics hardware, like on a laptop with an embedded graphics card. If your framerates are high enough you may not be able to see the drop.

Is there anything else I can do to give info about this? It should be easily reproducible since I was able to do it with the ArcGIS Runtime Samples app itself, unless it's very specific to my hardware. I can run any tests you think would help you identify the problem.

[RobBever]

A coworker of mine ran the sample application as well, and he also saw a lower framerate for 100.8, particularly for the Line of Sight example, with better performance in the 100.7 version.

That would indicate that it's not just the specific hardware that my machines have.

[RobBever]

Almost a year later and this remains a problem. I tested 100.11 and it also is far, far slower in 3D than 100.7, like 100.8, 100.9, and 100.10.

This tends to indicate that whatever the problem is, it hasn't been fixed. Did you verify my results? Is there any possibility of getting the performance in 3D in future releases back to where it was in 100.7? I'm basically stuck not upgrading until the performance problems are resolved. Thanks.

[RobBever]

Tried this in 200.0.0 and the performance is much worse than 100.6.0.

The Windows Game Bar stuff shows an FPS readout. When rotating the Line of Sight demo in 100.6.0 earlier, I got around 10-12 FPS consistently, while it was loading and when it was finished loading. (This is on a laptop, not a powerhouse.)

I ran the same in 200.0.0 right afterward, and the FPS was comparable while loading and then dropped to a consistent 6-7 FPS after everything was loaded.

I observed this years ago when I tried to upgrade past 100.6.0. The 3D performance was significantly degraded in my application as well, and I had to stick with the old version.

Is there any plan to fix this? It's easily visible in your own demo application. Please just revert to 100.6.0 in your demo app and run one of the complex demos like Line of Sight, and then run the same in 200.0.0 and see that the performance was much better previously.

I use the 3D display for my application, and the performance in the later versions isn't good enough for me to work with. I hope that you'll make this a priority to fix.