Performance degradation when using null tiles

[TimPushkin]

Note: this issue only happens on one of the phones I have, Samsung Galaxy S10e, API level 31. I cannot reproduce it on emulator or any other Android devices that I own (some of which are less performant), including other models from Samsung. I did a factory reset of this phone, but the issue still persists, so I worry that it can also occur on other phones..

When a TileStreamProvider returns null for some tiles scrolling past these tiles becomes very laggy which is demonstrated on the following videos:

1. Plain MapCompose "Adding markers" demo (the marker is just a reference for the next video). I'm scrolling the map in circles and it is very smooth.

https://github.com/p-lr/MapCompose/assets/71890197/dc38a32a-9b21-4cc1-aa2f-676b868e1e07

2. The same demo, but the tile provider is just TileStreamProvider { row, col, zoomLvl -> null }. Again, I'm scrolling the map in circles, but you can see the lag because the marker is jumping instead of smoothly moving in circles.

https://github.com/p-lr/MapCompose/assets/71890197/8cbf4395-28ba-426b-aad2-528f4533e7ba

3. "Simple map" demo with the original tile provider implementation (which returns null if a tile is not found in assets), I deleted each second tile in the top half of the map and left the bottom half unchanged. Sorry for the video compression, but it can be seen that scrolling on the bottom half where all of the tiles are present is smooth and on the top half where some tiles are null a severe lag is present.

https://github.com/p-lr/MapCompose/assets/71890197/b3383573-ad1f-4e26-b1a9-0cd7effc46dd

[p-lr]

Thanks for all the details. I cannot reproduce on my devices. I made an attempt in try-fix-#102 branch, but I'm not convinced that my changes will make a difference.

[TimPushkin]

No, sadly, this doesn't make any difference. This was actually the only change I tried myself but forgot to mention.

[TimPushkin]

I've collected some profiling data while scrolling in circles just like in demo 3 thinking it might help, though I understand that it is hard to fix an issue you cannot reproduce.

1. CPU and GPU load collected via Samsung's built-in "GPU Watch" utility. Looks like it is the CPU that gets heavily loaded.

⠀Usual	Nulls

2. Android's Profile GPU Rendering histogram (the link explains how to interpret it). A large portion of janked frames' time is "Misc Time / VSync Delay", which, according to the link, may indicate that the main thread is overloaded.

⠀Usual	Nulls

I've done the same profiling on another Samsung phone I have which doesn't have the issue, and there the collected data is the same for normal and null tiles in both cases, i.e. no such spikes in CPU load or frame time.

[p-lr]

Thanks! I've pushed a new change in the try-fix-#102 branch. I disabled tiles rendering entirely. If the lag is still present, then we'll know this has nothing to do with the GPU. However if the lag disappears, it'll be interesting. P.S: There might be a switch from hardware accelerated mode to software rendering when tiles are missing.

[TimPushkin]

The lag is still present

[p-lr]

Alright, so this tells us this isn't related to a rendering issue. I made another change :

• re-enabled tile rendering
• simulate a tile loading with a delay

[TimPushkin]

The lag is still present, but it happens much more rarely: I have to scroll around null tiles for ~10 sec for a single jank to appear (but when it appears it is roughly the same in duration).

[p-lr]

In the meantime I tried to switch the entire processing on the main thread on my device, and couldn't reproduce the lag even in those extreme conditions. So I'll take the time to think about your findings. Thanks again!

[p-lr]

Also, did you always had this issue? When did you see this for the first time (roughly)?

[TimPushkin]

As I described in #101, until recently I haven't tried using null tiles and used fully-transparent images instead. So I basically reported this as soon as I noticed the issue.

[p-lr]

I made a significant design change regarding null tiles, in order to limit some processing. Could you have a look?

[TimPushkin]

Tried it, works smoothly now!

[p-lr]

Alright! Again, I'll take the time to do more testing. Thanks.