Overlay image layer performance issues (low-res background)

[zomnium]

Hello!

In a project we use an overlay image layer to show a low-res JPEG image as a background, it is the size of a small country (the Netherlands). We do this because sometimes the loading of tiles take some time. The grey background makes it hard to navigate when they are still loading and it improves the perception of lower loading times. On top of this layer we add additional layers served from GeoServer and some markers/polygons.

Code of the static background layer:

OverlayImageLayerOptions(
  overlayImages: [
    OverlayImage(
      bounds: LatLngBounds(
        LatLng(50.736, 3.165),
        LatLng(53.5404, 7.383),
      ),
      imageProvider: AssetImage('assets/images/map_background.jpg'),
    )
  ]
)

The image itself is just a 3,6MB compressed JPEG, we also tried <1MB JPEG, but both create performance issues. Mostly on iOS, which has paint gaps of 30 seconds and sometimes crashes the app entirely. So probably the cropping is too heavy? Although Android doesn't seem to have much of a problem. An alternative would be to use local stored tiles but with all the zoom levels this would need a lot of storage.

Are there any alternative approaches to accomplish something this?

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[github-actions]

This issue was closed because it has been stalled for 5 days with no activity.

[magnuswikhog]

Did you ever solve this?

I'm having the same issue but in my case the overlay PNG is only 200 kB.

So far, it only seems to happen on the iOS Simulator, not on real devices. After activating a semi-transparent overlay layer from an AlertDialog, the app freezes for 20-30 seconds when popping the dialog. Usually (but not always) it also crashes without any error messages after being frozen for 20-30 seconds.

[ibrierley]

If using a simulator, I assume its using debug mode, which has a lot of slowdowns I think on iOS simulator only. My crude understanding is that it needs to use software mode for rendering and there are other things unoptimised to allow hot-reload.

So I suspect it's not a flutter_map issue, but a temporary combination of flutter and the simulator. I may well be wrong though, so it would probably good to test it on an actual device, and if it still has a problem put some minimal code highlighting the problem (also see if you can do similar without flutter_map itself to see if its more flutter or flutter_map, but appreciate that may well not be easily possible)

[magnuswikhog]

Thanks for the reply, I will see if I can pinpoint it more precisely. At first I thought it was the popping of the AlertDialog that was causing it, but after some more testing it seems to occur under the following conditions:

• Displaying an OverlayImageLayerOptions with a PNG (200kB) covering a somewhat big area (the entire country of Sweden)
• It only seems to happen if activating the OverlayImageLayerOptions layer when the map is zoomed in a lot (zoom level >14)
• Regardless of the Simulator setting Debug/Graphics quality override/Low quality

It's as if there is a surge of memory usage when activating the layer if the map is zoomed in. If I activate the layer when the map is zoomed out so that the entire image overlay is visible, it's fine. Also, if I activate the layer when zoomed out, and then zoom in, it also seems to be fine. So it seems to be somewhat related to zoom level and initial display of the OverlayImageLayerOptions layer.

[lvxduck]

I'm having the same issue as you. My overlay image is PNG (1MB).
I confirm that the lagging is just happening when the map is zoomed in with level >14.

[zomnium]

Sorry, I missed some comments. We did solve it, but a bit differently. TLDR: avoid immense scaling of images in iOS, it will have serious performance issues.

Options we tried with pros/cons:

• Our main issue was the loading performance of the tiles, it took way too long to render. Therefor we wanted a low res background to improve the loading experience. Because with a low resolution visual you could still navigate and find your way (because you still see the obvious landmarks).
• The main issue with this approach, a low resolution image as background, is that it will need a lot of scaling. If my memory is serving me well, this is where iOS has troubles. Android can handle it for some reason, but iOS will show serious performance issues. The app even gets unresponsive in some cases.
• We experimented with a MBTiles layer, with low-res tiles. It is quite an effort to make and compress. Another downside is it has tiles for every zoomlevel, that solves the performance issues with scaling, but that will make it quite large if you need to support a larger area with a lot of zoom levels. We didn't want to have that in our package and repo, making a download mechanism is an option but not ideal. Maybe for other projects it can be a solution.
• We went back to GeoServer and did a lot of optimalizations there, making sure all tiles are prerendered, cached and ready to go. There is a REST API you can use to manage GWC's cache. That gave us the snappy result we where looking for. The low res background would still have been nice for area's with a bad signal of course, but that would just have been a bonus.

I hope it helps!