Abysmal performance with x86_64 Android emulator

[westnordost]

(At least) on my Android emulator API 34 (x86_64, no google play services), after zooming, the performance seems to become abysmal, or at least both panning and zooming results in very jerky movements. See the video. It starts out fine, but as soon as I zoom in or out, the issue appears. Zooming back (exactly?) to the start zoom level seems to solve the issue.

long.mp4

On my phone, I cannot reproduce this, as far as I know, it might be an issue that only surfaces when using emulators. Or only affects x86_64 architecture.

For reproducing this bug, I removed everything from the map that is not plain display of the background map, i.e. no StreetComplete-stuff happening there.

More Information

I did record a callstack with the profiler, viewable in Android studio (not at the same time as recording the video, but later, doing the same map movements). But if the issue is reproducible for you with an emulator, it's not going to be worth much if you can just use the profiler yourself. I had a short look at the profiler output and I wasn't able to learn anything from that (I know none of those function names, e.g. a lot of time is spent in __traceiter_sched_switch, whatever that may be, and as far as calls directly made from libmaplibre.so are concerned, GL2Encoder::s_glUnmapBuffer seems to take the lion's share of the time.).

Platform information (please complete the following information):

• OS: Android API 34, x86_64, no google play services

• Version 11.0-pre6

• Host system specs: Windows 10, CPU: AMD Ryzen 7 5700X, GPU: NVIDIA GeForce GTX 1660 SUPER, RAM: 32GB

[louwers]

Can you reproduce the problem with one of the MapTiler styles? These are used a lot for development.

[westnordost]

Can you give me a link? Do I need some API code?

[louwers]

https://www.maptiler.com/

[westnordost]

Here it is with the MapTiler "streets" style. It feels even worse. Note that zooming might not have anything to do with it, as it was already jerky from the start:

long2.mp4

[westnordost]

@louwers could not reproduce this issue on an emulator running on a Mac with a M3 processor. That's an ARM architecture, so he probably used a system image with the arm-v8a ABI rather than x86_64.

[louwers]

After bringing this up with the graphics engineers working on the drawable renderer, we came to the conclusion it does not make sense to do optimization for the Android emulator. So thanks for the report, but I have to close this.

I hope despite the bad performance it's still manageable, maybe developing on different hardware is an option.