Android 8.0.0
HTC 10
Just after updating the app

I can repoduce this too... But not just since this version... Restarting the app might help to solve the issue temporarily for you...
Restart sorted it, cheers
On 9 Feb 2018 22:38, "ENT8R" notifications@github.com wrote:
I can repoduce this too... But not just since this version... Restarting
the app might help to solve the issue temporarily for you...—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/westnordost/StreetComplete/issues/850#issuecomment-364559033,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AD6K2zugXRKQYGVdMS5-QuSpwtW5n7Swks5tTKzegaJpZM4SAesL
.
Anyway, what was the reason for that? Was ist the first start of the app after the update?
For me it was.
I'll do a few more restarts, reboots to see if it reoccurs
On 9 Feb 2018 22:47, "rugk" notifications@github.com wrote:
Anyway, what was the reason for that? Was ist the first start of the app
after the update?—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/westnordost/StreetComplete/issues/850#issuecomment-364561472,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AD6K2wH8aPy8zUcK3I2WhNyD8me8gHn9ks5tTK7sgaJpZM4SAesL
.
Theoretically, this bug may occur if a scene update is triggered and tangram-ES calls onSceneReady on
the listener before the quest graphics finished initializing.
However, the quest graphics are created synchronously before loading the scene and the scene updates associated with loading the quest graphics are committed together with loading the actual map, also synchronously. StreetComplete does not trigger any further scene updates. So, I don't see any way how StreetComplete can trigger a scene update before the quest graphics are loaded.
I suspect a bug in tangram-ES, but the problem is not reproducable enough that I am willing to create a bug over there. So, let's simply monitor this issue.
I often switch back to this app and no icons appear, moving the map just a little bit seems to trigger a redraw and all icons reappear on the map. Not a big deal, but might be the same bug, just that the drawing engine react slightly different - in my case they are just opaque and in his case black.
I think yours (@RubenKelevra) issue might be #724 or maybe #437
And the initial issue can't be fixed by moving the map AFAIK...
@ENT8R yeah, sounds more like #437 to me, but this ticket is already closed. I think it's not that big of a deal, but you might still want to escalate this?
Could also reproduce this at the very first start after the update to 4.0. The map could be moved and it were really the quest icons, which always were black. One restart and it is fixed.
I can reproduce this on android 7.1.2, on a new SC install (4.0).
A restart of the app or the phone does not fix this.
The icons have appeared at some point but this is an exception.
This may have to do with the fact that the phone is rather old and has rather low memory (1.5GB RAM).
Note: forcing GPU rendering of 2D objects in android developers options seems to fix the issue for me.
Correction: it doesn't.
I also experience this, e.g., when SC first crashes for some reason and then, at the next start, this issue happens.
BTW, could just reproduce this with a fresh installation of v 6b78a575fe4fb9f61652b3239be3a2a6060b90e7. LineageOS 14.1
After some time of using it and going into some menus (settings etc.) the issue just disappeared.
I've noticed that before the app may show these black things, it hides all quest icons, i.e.
This seems to be happening a lot more for me lately, and it can sometimes take many closes and restarts of StreetComplete for it to come good.
Hmm, I was about to create a ticket in tangram-es after all, but while having another look at the code to describe a reproduction, I found a possible race condition when creating the icons bitmap:
For a faster startup, a background thread starts creating the icons bitmap on application start (takes about 0.8 seconds on my phone). Then shortly after, when the map is being initialized (about 0.6 seconds after application start), the main thread is supposed to wait for that background thread to finish creating the bitmap, saving it to disk and then use it.
What actually happens, though, is that the main thread ignores this and always creates its own bitmap. Now I am not sure what constellation of two threads competing to save bitmap to the same file on disk may result in no/completely black bitmap to be loaded, but that behavior was definitely wrong, so likely the cause. If not the cause, then at least the startup will be about 0.6 seconds faster.
The specific mistake was that the class which creates this bitmap was not used as a singleton.
In other words, I will close this, feel free to reopen it in case it still happens with the upcoming v8.2.