Performance when zooming on Android

[Helium314]

I'm currently working on migrating an app from no longer maintained Tangram ES to MapLibre, and noticed that MapLibre performs noticeably worse when zooming with many icons (symbols) displayed.
This seems to be specifically about symbols. I noticed that it's much better when using circles instead, or when reducing size of the symbol bitmaps.

On Tangra, zooming the map is very smooth (even on a 10 year old S4 Mini and when the CPU is doing heavy work).
When trying the same in MapLibre (10.0.2 on S4 mini, and with a newer phone and v11.0.0-pre4), zooming is somewhat bumpy / laggy. This gets very noticeable under high CPU load.

Now I'm wondering about two things:

• How does Tangram manage to stay so smooth? Can all that stuff be done on the GPU?
  (I am aware that this is the wrong place for expecting an answer. Still I wonder)
• Is there anything that can be done to improve performance (while still displaying the same number of symbols)?
  • From the app's / my side (it also happen when features in the GeoJsonSource are not touched during zoom)
  • From MapLibre side

[westnordost]

Is it also jerky for when you zoom by hand, i.e. not zoom into a quest but just press +/- buttons?

I can reproduce it being jerky, but only when (in dev mode, which is slower and when) zooming into quests. There are more things happening there at the same time on the UI thread:

• the quest form is being inflated and displayed, i.e. nothing to do with MapLibre
• several GeoJsonSources are updated. I wonder if every setting of geojson source and/or changing of the style triggers a redraw, or if that redraw is only posted onto the next render frame

[Helium314]

When doing nothing but zooming out it can be quite noticeable on release APK. Sometimes (more rarely) even when zooming in.
I don't think GeoJsonSource update is happening, as the area was loaded before (and when zooming in around z15-z16 there should be no source update anyway)

[louwers]

That MapLibre Native on Android spends a lot of time encoding (CPU) is a known problem. Performance is a continuous area of concern for the team working on the internals. They are investigating moving more work to the GPU, but it looks like there are not many quick wins in terms of performance unfortunately.

I don't know how Tangram! Maybe @sjg-wdw knows it?

[sjg-wdw]

Sure, I remember Tangram. WhirlyGlobe was also very efficient with symbols, depending on how you added them.

Rather than raw performance, I'd look at how you're setting up the style. If there are a lot of sub-layers or you're forcing the system to sort them in some way that can really slow things down.

The mention of symbol size is curious. There's no particular reason larger images would be any slower. Unless there's some strange setting forcing a rebuild of the atlases.

[Helium314]

The mention of symbol size is curious. There's no particular reason larger images would be any slower. Unless there's some strange setting forcing a rebuild of the atlases.

That was something I remembered from more than a year ago, I can go re-check it when I find some time.

If there are a lot of sub-layers or you're forcing the system to sort them in some way that can really slow things down.

Symbols are sorted only by the order of adding, I found that this the fastest way of "sorting" (only need to re-order the list once).
Not sure how many layers we have, maybe ~30 defined in app, and some more for the background map.

[westnordost]

With sub-layers, you mean layers?

For z-order, we are using SYMBOL_Z_ORDER_SOURCE, which is as far as I know the most performant option.

Anyway, if the zoom is jerky, it doesn't necessarily mean that the CPU is doing too much, only that too much is done on the UI thread. @Helium314 did you try the profiler in Android Studio? At least for anything done on the Java-side, it may reveal what is taking so long during zooming.