SceneLoader.ImportMeshAsync is blocking all tabs in the browser

Why is this happening? When I’m loading a bigger model (200 MB) the browser even shows a “Page is not responing” alert. The blocking starts after the file gets loaded. I believe when the model gets created in the webgl context the overhead is too big and it’s blocking the whole browser. Can this be somehow managed?
Thank you!

Hey Roland can you link the playground? :slight_smile:
(If it’s possible)

You could try to use babylon on a worker thread with offscreen canvas.

A lot of things can be serial during load and a huge model might take a long time to parse for instance. As @msDestiny14 mentionned a repro would help.

Don’t forget the handy “Loading” image feedback you should give the user while you wait. :joy:

Yes, I’m doing in with a cool particle effect in a webworker and offscreen canvas :smiley: but it gets blocked too. And the CSS animations stops as well. The whole browser becomes unresponsive. I can’t even change the tabs while it’s parsing/creating (whatever is does). This is happening with smaller models (30MB) too, however the blocking period is much shorter but it totally disrupts the particle loader effect and the css animations. :frowning:

I’ll create a PG.


1 Like

The progressive load page might be of some help too? :smiley:

Hello! :slight_smile: Thank you for your suggestion! This unfortunatelly doesn’t solve the problem because the problem starts after the model is fully loaded. The loading phase is smooth. I’ve already created a PG and shared it with @msDestiny14 in a private message. I couldn’t share the model file in a public post. :frowning:

Maybe related? Windows/chromium angle issue with some gl rgb thing causing super jank after load. SRGB8_ALPHA8 blocks the main thread · Issue #22631 · mrdoob/three.js · GitHub

It seems like using a webgl1 or webgpu canvas could check for this issue specifically, maybe worth a try


Thanks for sharing this link! I’ve just discovered that removing all the textures helped the situation and it loads smoothly. So it seems to be heading that way! I was curious and tried to load the model in three.js and it was like 5x worse than in BJS and it didn’t load properly at the end.

1 Like

@roland toji posted a fix in the threejs issue, which is to use gl.texStorage2D to load the textures. Do u think its something babylon should swap in?

1 Like

Hello @jeremy-coleman !
I am quite suffering from this “issue”. When loading the main 200 MB glb file in my project which has around 150 MB of textures the whole browser with all tabs is blocked out for 15-20 seconds (running on a 5Gig/i9). If there is a chance to make it better I will welcome it for sure!
Thank you!

Also as a tiny follow up to this. I tested it with Roland on my machine and didn’t get the same blocking as he did. :thinking:

It did take a while to load. Maybe 30-40 seconds. But I was able to tab between the many chrome tabs I had open.

Lucky you! :slight_smile:

1 Like

@msDestiny14 are you on windows?


Interesting is, that I’ve tested it on my notebook and it’s the same. It’s blocking the whole browser, Chrome latest. Both my PC and desktop runs on Win10 and on a 3080 GPU. Maybe the GPUs are causing this?

Edit: one runs on Intel, other on AMD

since you aren’t loading the textures directly , its harder to tell if its the srgb thing. Can you first try to force webgl1 and/or WebGPU and see if it stays slow (thats the fastest way to check for the srgb issue) ? But since you’re importing from GLTF, that’ll be the place to check next

@roland can u check this and see if it help your problem?

I expected this was the case , but wasnt sure so i had to check first. The babylon GLTF loader is using srgb , so changing engine may not actually help you any.

here is an extension using srgb for pbr materials. may or may not apply idk.
.Babylon.js/MSFT_sRGBFactors.ts at master · BabylonJS/Babylon.js · GitHub .

and more importantly
.Babylon.js/glTFFileLoader.ts at master · BabylonJS/Babylon.js · GitHub

the default gltf loader has useSRGBuffers set to true by default. Try setting useSRGBuffers to false.

Also, maybe helpful for context. (from the model-viewer issue)
you can change the version from 1.8 to 1.9 to see the difference. .

I can confirm it’s a WebGL2 issue. I’ve tried all available modes on both Chrome and Chrome Canary. WebGL2 makes both browsers unresponsive. WebGL and WebGPU are working well.

I think adding this before you load the asset this should fix it.

BABYLON.SceneLoader.OnPluginActivatedObservable.add((loader) => {
    loader.useSRGBuffers && (loader.useSRGBuffers = false)