[moron4hire]

I'm curious to know more about their statement that loading textures in a WebWorker caused additional performance overhead versus loading them in the main thread. I have my own WebWorker based texture loading system and it is significantly better than not using it.

At the risk of stating the obvious, as OP seems pretty well on top of the Web API game, did they remember to mark the texture data ArrayBuffer or ImageBitmap as transferable?

Though, I suppose my metric is "number of dropped frames", not "total time to load" and I haven't actually measured the latter. My project is a WebXR project, so the user is wearing a VR headset, wherin dropped frames are the devil.

[micrio]

I have to admit that I didn't dive 100% into what made this difference exactly. It just worked better without webworkers.

I just dived into the git history, and it turns out I didn't use the buffers as transferable. Perhaps that was it! I'll definitely check that out later, thank you for pointing this out!

[micrio]

A follow-up on this one. Now textures are downloaded by WebWorkers using the transferable buffers.

Over multiple benchmark runs this results in another 32% CPU performance gain (WebWorkers vs single thread texture downloads)!

Thank you for point this out to me!

[moron4hire]

No problem. I just happen to be working on a somewhat similar project. It's strictly 360 photos and it's built around our company's foregin language instruction services, but I've had to deal with/am currently dealing with several similar issues. Indeed, the next major tech change I had planned was to also implement my own WebGL code and get rid of Three.js. I'd like to see if I could get the WebGL code running in a WebWorker with OffscreenCanvas, but I'm as-yet unsure if that will work with WebXR.

[XCSme]

> it turns out I didn't use the buffers as transferable

Not using transferable has HUGE performance hits, it can take even seconds to transfer larger buffers.