Re:Migrating a JavaScript Library from JavaScript to WebAsse...
by micrio on Thursday February 11, 2021 @04:20AM
(#26099707)
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!
Re:Migrating a JavaScript Library from JavaScript to WebAsse...
by micrio on Friday February 12, 2021 @07:15AM
(#26112845)
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!
Re:Migrating a JavaScript Library from JavaScript to WebAsse...
by moron4hire on Friday February 12, 2021 @12:23PM
(#26116045)
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.
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.