What could cause a program to reset a phone background?

I’m getting quite a strange error where sometimes one of my scenes, when run through the play link on a phone (Pixel 4a) will reset the phone’s home background to the default background.

Does this problem ring any bells for anyone? I can’t share the project due to restrictions from my employer and I can’t narrow it down to a smaller project with the same issue because I don’t know what to narrow in on.

Extra context: I’m using 8thWall for WebAR, specifically world tracking for this scene

My current thought is that it might be a memory leak caused by not cleaning up event listeners properly. Are there other things besides memory leaks that would do something like this?

Thanks for your help, I know this is pretty vague but any tips or ideas are highly appreciated!

I’ve never seen an issue like this where a browser app can change the system home screen :thinking:

Does this happen on other phones?

1 Like

Great question, we just tried on some other phones and narrowed it down a tiny bit.

It does not reset the background on a google Pixel XL

Interestingly, it seems that it only resets the background when the Pixel 4a is running a live earth background. That definitely means it’s less of an issue, but I’m still worried that it has the potential to change anything outside the browser.

It does sound like a browser issue that the app could be triggering. A couple of things I would do to investigate:

  • install chrome beta and/or canary and see if it happens there.
  • look at memory usage of the app with our profiler and chrome devtools. In particular, VRAM usage.
1 Like

I’ll try those - Thank you!

Sorry one last follow-up

What should I be looking for in the VRAM usage that would be alarming?

Anything high, eg if it’s using 500MB of VRAM then perhaps in combination with Google Earth, it might cause some sort of crash.

Or if it creeps up over time is something to be concerned about.

It be good to check the overall memory usage in Chrome devtools too.

1 Like

Whoops it’s got over 600 VRAM, that’s probably it, thank you! I had been saving making a gradual loading / unloading system for later but with this in mind I should probably get that started right away.

Our profiler should say where that is being spent. If it’s on textures, consider using basis compression.

1 Like

Thank you so much!
Using Basis Compression I was able to bring the VRAM from 600 down to 250 and now it runs much better.

2 Likes

Good to hear! I wonder where the other 250MB is coming from :thinking: That still seems high.

1 Like

We have a couple of pretty high polycount models (Specifically a tree that has ~400,000 verts)

We’re also using 8thWall, I’m not sure if its’ world tracking would also contribute to VRAM?

Those would be my guesses but I’m not 100% on anything

Update: I remembered that I could check what it’s coming from.

The breakdown is:
Index buffers: 15
Vertex buffers: 84
Texture assets: 114

plus a tiny bit from other stuff for a total of 245.

Does any of that sound like it’s way higher than it should be?

Texture assets still look high at 114. It might be worth looking at the dimensions of the textures and see if they need to be that big.

Depending if you want to dig further is to start disabling/removing stuff to see what

1 Like

I’ll talk to our artist and see what the options are. Thank you!