ENC performance is poor on macOS using QML. How can I improve it?

[KennSebesta]

Background:

I am using the AddEncExchangeSet QML example and I notice that ENC performance is very poor. I am loading a single random NOAA chart, so it's not the case that I am overloading the CPU by trying to show an entire continent's worth of data.

I am using the default display settings.

This is on macOS 10.15.4, on a 2019 Macbook Air.

Observed behavior:

When panning, it takes 2 or more seconds to update the map. This includes immediate backtracking, where that section of the ENC was just displayed mere seconds prior.

These performance issues make the ENC challenging to use on the desktop, and I imagine impossible on mobile.

Desired behavior:

Ideally, the map would be as reactive and smooth as the BaseLayer maps.

===================================

Is there a way to improve ENC viewer performance? I have looked through every ENC-related page in the SDK and the only mention of performance I can find is a reference to where the SENC files can be stored.

Am I missing anything? In particular, is there a way to direct the ENC to stay cached in memory longer, and to pre-cache neighboring data outside the viewpoint extent?

[LucasDanzinger]

Do you see this same performance with the dataset mentioned in the OfflineData section of the sample? https://github.com/Esri/arcgis-runtime-samples-qt/tree/main/ArcGISRuntimeSDKQt_CppSamples/Layers/Add... 

That's all I have for data locally, and it works well on my year-old MacBook Pro.

[KennSebesta]

Yes, I see similar performance delays when using that dataset. Although I want to be clear that the delay is not consistent, it is highly dependent on the zoom level, with it slowing down the deeper the zoom. It also somewhat feels like it might be a function of how much data is in the ENC and how much of that data is visible in the viewport.

I suspect your MacBook Pro might be substantially faster than my MacBook Air. Have you gotten a chance to try it with mobile?

As it stands, on my computer it is not be possible to rapidly scroll and pause at a feature of interest. Instead, I have to pause scrolling every page-width in order to allow the screen to regenerate.

Is there no way to adjust the caching? In particular, is there no way to keep already-rendered screens in memory?

[LucasDanzinger]

Can you upload a video of what you are seeing? I tried on my Android device and it seems to work ok, but maybe I am at a different scale or panning differently than you

[KennSebesta]

That certainly does look very good. Which Android device were you using?

I tried it on a 2021 iPad Pro 12.9" and it works equally well to your example. My issues might be platform dependent, and in particular RAM-constrained platforms. (I.e., I should close out all the Chrome tabs and see how repeatable it is. : )

I guess a feature request would be to have some tuning params for ENCs. Even though tiles load quickly on our mobile platforms, they still have a loading delay and this seems like something which would be preferable to avoid. On faster platforms, I'm sure the user would appreciate the benefits of preloading neighboring tiles, and not dropping from memory the immediately prior tiles.

[LucasDanzinger]

I'm using an Android Galaxy A51. 

I'll pass on the feedback to add some parameters like this. We have similar caching/loading options in feature layers and tiled layers.

[HydroExpert]

You may be hitting an issue similar to this one: Solved: [Solved] How to get reasonable performance using E... - Esri Community

[KennSebesta]

Good thinking. I believe that particular issue has been resolved, but I'll try it with a mouse just to be sure.

The issue improved on my computer when I freed up resources, so I feel this points towards a resources  limitation. However, on this same computer no other map displays this problem, and on a brand-new iPad Pro the tiling behavior I describe above is still present (although the system is fast enough that it's merely noticeable, and not an impediment). This hints that the underlying viewer might not be optimized for anticipating user inputs.