Unity in a web worker?

Is it possible to have Unity run inside of its own web worker and have it make calls to the DOM for when it wants to display its frame?

 

Working on improving the UI responsiveness of my web page. Was hoping to offload all of Unity's calculations to a web worker so that it doesn't bog down the rest of the UI elements. Right now when Unity starts crawling (say 5fps) then the whole webpage suffers

 

Are there plans in the future roadmap to allow this? Or other threading tools?

I understand your hands are tied by the capabilities of the major browsers, but wondering if/how the state of things have changed in the last 8 months?

 

Bump.

I have a slightly different use case: I want to have very basic scenes load/run as quickly as a Three.js (3D) or Pixi.js (2D).

I can get the files down to less than 4MB which is comparable, but after loading these 4MB there's around 3 seconds where the browser thread is locked while it (I'm only assuming) JITs the Unity engine. If I could at least get whatever is going on there to not block the DOM, I could hide it with an intro video / animation / etc (thus the focus on web workers).

It looks like you can spawn a worker directly from Emscripten via a native plugin if needed, which might come in handy for Asset Bundles, but of course you'd still need the engine for that.

 

Sure, that makes sense. I guess I was thinking more like the worker would load it, compile, then transfer back to the main thread, so that the containing script (Unity) didn't need to support workers -- but that's more of a generic solution unrelated to Unity now that I think about it. In theory if that worked though, you could play a movie or have some other interactive content playing full speed while Unity gets ready.

So better question, what's the fastest we can get a box to show up on the screen on a modern computer? I'm at around 3 seconds for loading the files, and around 3 seconds once the Unity loader is visible to see the box (6~7 total).

Steps I've found so far:
* Turn off precomputed and baked GI, light maps, reflection probes, and anything that bakes.
* Turn off shadows, strip down mesh renderers.
* No assets (textures, models), just simple geometry GameObjects and shaders.
* I've tried turning off static and dynamic batching, but don't think this makes a difference.
* .NET 2.0 Subset
* Don't pre bake collision meshes, shaders, assets, etc.
* Strip engine code
* 512 memory size (though I don't know if I could use this in prod... been benchmarking to 256)
* Exceptions off
* Data caching off (looking at first-time loads only).
* No splash images / icons / etc.

I can design around that for an intro scene, and load the real content with asset bundles - so literally just looking at how quickly I can get a box on the screen.

Maybe there's a hidden setting somewhere that would shave off another second? I realize I'm trying to make Unity do something it wasn't designed for, but I'm not making games; so the load time isn't perceived as a nessicary part of the experience, and need to get that down to compatible to Three.JS, Pixi.JS, Flash to Canvas, etc.

Alternate to the web workers loading Unity, I'll see if I can load a video in one today so that Unity can own the main thread.

 

I've made a minimal(ish) example of the load time I've been trying to reduce. This isn't a bare minimum test, but compared to the bare minimum it's not enough time difference to separate from the variance of general web load times.

https://github.com/xirvr/unity-webvr
http://xirvr.com/unity-webvr/

I was going to try a video in a web worker, but I started with a CSS animation and realized a video (or otherwise) in a web worker wouldn't help, because it's the DOM that's blocked, and you can't put the DOM in a worker. The color change is actually a better example of the problem though, as you can't have even a simple animation covering the load processes.

Just to make sure, in no way whining about Unity to WebGL, just trying to squeeze that last few drops of performance and wondering how it all works under the hood

Update: I was wrong, I stripped it down this morning and it's a noticeable difference (it's back down to 4~6 seconds now). Updated the repo and demo. Ignore the reversed quaternions on mobile and VR, haven't addressed that yet and is unrelated.