Many Performance Issues With 4.2 and iOS/Mobile

Actually I am seeing in spector some new texture created when we come back the second time.

Are you using features like asset container and or cloning the models in the scene every time we open the custo ???

image You can see the memory created per time spent in the application here.

No, not deliberately. Our flow is supposed to be gltf => load textures => update customizer => update textures if changed => update colors. I’ll take a closer look to see if that’s been broken.

Else would there be any way to run the code locally for me tomorrow ???

I could try and have a look from your code (if I can run the front end custo isolated from your private data obviously)

That may be hard. I’ll see if there’s a way to share via PMs.

no problem the playground would still be better if possible, but I know it might be easier the other way around.

It looks like a mempry leak to me as well.
I did tests on macOS and Safari 14. Just by resizing the window a few times, I can crash the page. Allocations with Activity Monitor can reach up to 8Gb.
Same resize repro with Firefox and memory tops 300Mb
And I could get that issue with 4.1.0-beta.6. and v4.2.0-beta.10 with webgl2 exp. feature on or off.

I could repro the issue with a random PG, macOS with Safari 14:

  • load activity monitor
  • load PG
  • resize the browser windows until you get the message ‘this webpage was reloaded because it was using significant memory’
  • safari will report something like 3 or 4 Gb memory used

As I’m having doubt about Safari more than babylonjs, I’ve tested a sample from threejs. same steps: load the sample, monitor memory and resize the window.
And we have the same behavior with automatic reload when Safari uses 3/4Gb.

Morning - We were seeing issues 2 and 4 in the list occur with Google Chrome as well on iOS and Android. We are seeing #1 only occur on iOS Safari. So that could be a Safari issue for sure, but we suspect we have other problems since 2, and 4 are affecting all mobile devices we’ve tested. And they only occur when we upgrade our Babylon version.
So we certainly could have multiple issues going on. My hypothesis is that Safari is just handling the memory issue differently than other browsers and may be forcing a refresh instead of just slowing down like we are seeing on Android. That’s just a theory though.

Corrections on the issue list:

  1. Safari 14: If you open the page on iOS Safari 14 and rotate your device, there is a context lost error and WebGL crashes.
  2. (All Mobile Devices): We’ll see calls to load KTX files with malformed URLs. These will be re-appending the KTX extensions, so we’ll see something like “myfile-dxt.ktx” changed to “myfile-dxt-dxt.ktx”.
  3. Safari 14: Open the page, and choose “customize”, then “done”, then “customize” again, then “done” again, and then scroll the page, you’ll see the error that says “a problem repeatedly occurred”. This seems related to the “context lost” issues but is also forcing the page to refresh multiple times. Using v4.1.0-beta.6 the problem cannot be reproduced.
  4. (All Mobile Devices): If you repeat the steps above on any mobile device there is a noticeable slowdown when scrolling the page affecting many browsers and devices. It could just be Safari handling it differently than Chrome, etc…

I think ktx issue is different from the context/memory issues. Maybe @Evgeni_Popov can help on this one.

Regarding ktx, you must not put “-dxt” in the file name: the engine will complete the file name depending on the compressed texture formats supported by the GPU.

Correct. That’s our understanding as well and what we are doing. However, in Babylon v 4.2.0-beta.10 it was adding the “dxt” twice in some cases and in other cases the extension is missing all together. It’s intermittent but definitely happening a lot for us. I’ll see if we can create repo steps, but so far it seems like an intermittent problem.

Ok we found a hint Babylon.js Playground changing the canvas size seems to leak…

“Funnily enough” just this makes it crash :

Basically without anything if the canvas size changes too frequently it looks like Safari can not handle it… We will see if a workaround to debouncs it can be applied for Safari. In the mean time, we should contact them as it definitely sounds like a bug on their end… :frowning:

1 Like

Just to clarify this one because it might be a clue, we’re setting the texture URL to png and then adding the available formats and this works 100% of the time.

When the context lost error happens (which we only see on Safari), we see an immediate call to the malformed textures right before the shader compiler throws an error and we see the shader code in the console. My suspicion is that in the recovery code for textures, it is attempting to look again at the available textures and re-append the extension before the texture fails to upload to the GPU since the context is irretrievably lost. This might be a totally different issue but is just revealed in this specific scenario.

I tested this on Chrome iOS14 and it crashes as well.
It takes a lot longer, but webgl will crash and do an “Aw Snap”. Screen Shot 2020-10-22 at 7.48.37 AM

This is expected cause Chrome on IOS is basically Safari :slight_smile:

1 Like

So we currently see 2 issues only:

  1. Safari leaks on canvas resize…which ends up creating the context lost
  2. On context lost the texture are not recreated properly

I will look deeper into 1. with @Cedric today. @Evgeni_Popov could you have a focus on the second part ?

Yes, having a look at that.

Note it is a warning in the console, and because the url can’t be loaded (404) it reverts to the original url which is ok and can be loaded. But the warning should not be there in the first place.

1 Like