Quest icons not shown until map interaction (zooming/panning), happens only in emulator

[matkoniecz]

Scan for quests.
Wait long time. Wait longer.
Zoom out - and quests finally appear.

Versions affected
afd4dce

[matkoniecz]

Curiously it is not reproducible on my phone. Emulator is Android 10 (API 29), Nexus S. Happens both with software and hardware graphics (hardware graphics have some extra issues with small dots).

Physical device is Android 10 Mi A2 Lite, so maybe it is emulator bug - not SC bug.

[westnordost]

Could this be a tangram-es issue?

You can add a breakpoint at PinsMapComponent::showPins. Is it reached?

[matkoniecz]

It may be something random, but it appears to me that bug is no longer happening if I build it in a debug mode :)

And once again:

Debug with breakpoint: triggered, works
Debug without breakpoint: works
Normal mode: broken

Wonderful.

[westnordost]

What do you mean broken? Does the code reach showPins or not?

[matkoniecz]

What do you mean broken?

like in the original report - icons not shown until zoom in/out

Does the code reach showPins or not?

In debug mode: yes, and it works

In normal mode: not sure. And it does not work (icons not shown until zoom in/out)

I added logging to that function to make it visible without breakpoint. With that addition it is logged and it works as expected.

Once I removed logging - I lost ability to check is it running and guess what? New quest pins are not visible until I zoom in, zoom out or move map.

Is it happening on your computer? Maybe I should run RAM check or something.

[westnordost]

I also sometimes observed that. I think. But also already before v32.0,

Sometimes one had to move the map or zoom so that newly added pins to the map become visible.

[matkoniecz]

I also had some like that earlier, but never reproducible and consistent. Even if that one is behaving weirdly.

And idea how it can be attacked if both Log.wtf and enabling debug mode changes app behavior?

[westnordost]

No, no idea. Surely the log has nothing to do with that you can't reproduce it. Better maybe show a toast message instead so you see it also when casually using it or testing something else

[Helium314]

I also sometimes observed that. I think. But also already before v32.0,

Sometimes one had to move the map or zoom so that newly added pins to the map become visible.

Same for me.
Never bothered no report, since pins appear after the next interaction, and I couldn't reproduce it.

[westnordost]

That you can rather reproduce it on an emulator than on a real device might have this reason:

On a real device, you have a compass which changes its direction all the time. Since the compass direction is shown on the map, whenever you hold the smartphone just a little bit different (or because of background noise of the sensor), the direction that is displayed on the map is updated every few frames. So when the map is redrawn, tangram-es tells its listeners that the map view changed which is the same callback as when rotating or zooming the map.
What the app does when it receives that callback is to check for the displayed area if the quest pins have been pulled from DB already and if not, pull them from DB for that area and display them.

So anyway, since this is an old bug and one where I am relatively certain that it is not even be related to STreetComplete (but don't have the energy to "prove" that so that I can create an issue at tangram-es), I'll close this.

For anyone wanting to get to the bottom of this, the best way would probably be to build a custom version of StreetComplete where a toast message is displayed every time PinsMapComponent::showPins is called. If after download, the map view stays empty and such a message appears, the culprit is at tangram-es. If after download, the map view stays empty but no message appears, the culprit is at StreetComplete.

[westnordost]

That the compass updates all the time and thus triggers a re-render of the map view might also be the source of some battery drain. You are welcome to try out removing this direction marker from the map view and compare how this affects the battery lifetime.

[riQQ]

To add another data point:

On a Nokia 2.2 (device doesn't have a compass sensor) with Android 10 and StreetComplete 31.3 I have the following reproducable behaviour:

At a certain zoom level with StreetComplete in the foreground, when you turn off the display and then enter the PIN to unlock, StreetComplete briefly shows the pins and then hides them all. Moving the map around brings the pins back.

Is this the same issue / root cause or something separate?

[westnordost]

I don't know. I didn't close this bug because it's not a valid issue, but because of #2780 (comment)

You are welcome to try to get to the bottom of this.

[Helium314]

In case this is still worth fixing: calling KtMapController.requestRender() after setting features does the trick.

[westnordost]

Sounds good, if this does not lead to a performance detriment Am 15. März 2023 18:07:37 MEZ schrieb Helium314 ***@***.***>:

In case this is still worth fixing: calling `KtMapController.requestRender()` after setting features does the trick. -- Reply to this email directly or view it on GitHub: #2780 (comment) You are receiving this because you modified the open/close state. Message ID: ***@***.***>

-- Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

[Helium314]

If so, it's not noticeable. I guess it's just forcing what happens on every interaction with the map.