Streaming compilation will allow wasm code to be compiled while it’s downloaded, which might be beneficial to your content loading times, depending on how much code/data will need to be downloaded.
This feature can be enabled via PlayerSettings.WebGL.wasmStreaming = true;
The only difference in the generated build is that the wasm code file will have a .wasm extension, as opposed to .unityweb. So, for this to work you will need to make sure application/wasm mime type is added to your server configuration. Like for unityweb files, Compression also needs to be set accordingly to your player settings (none or gzip or brotli).
Note that there is a known issue in the latest Alpha which prevents the wasm file to be cached.
Multithreading is self explainatory. This enables internal native engine threads so that systems like AI, Animation, etc… can distribute jobs that will be executed by worker threads. C# multithreading, though, is still a problem we need to solve because of garbage collection
This can be enabled in your project via PlayerSettings.WebGL.threadsSupport = true;
There are several known issues at the moment that we are working on fixing, but the most important ones that you need to be aware of are:
the Wasm Heap cannot grow, so you will need to make sure it’s large enough for your content. There is an issue in emscripten about this.
there is no fallback yet: if the browser does not support multithreading, it will not fallback to a singlethreaded version. This is something we will implement though.
rendering is still on the main thread.
Here is an example of how you can enable multithreading:
PlayerSettings.WebGL.linkerTarget = WebGLLinkerTarget.Wasm;
PlayerSettings.WebGL.threadsSupport = true;
PlayerSettings.WebGL.memorySize = 512; // tweak this value for your project
Firefox and Chrome both implement the required Shared Array Buffer and wasm multithreading specs in the latest builds but they are still disabled by default so you will need to:
Firefox 65+: set javascript.options.shared_memory to true in about:config.
Chrome 73+: enable chrome://flags/#enable-webassembly-threads and chrome://flags/#shared-array-buffer.
Note that this is an experimental feature, therefore will have some rough edges.
Is rendering on a separate thread coming in 2019.1? From profiling my webgl games, it seems like the only thing that will give a noticeable speed up. I’m assuming the issue is the scripts called on eg OnPreRender(), image effects etc?
What about burst and ECS job system? This system does not require GC or any native API dependencies. It seems like a great candidate for early threads implementation (easier than C# threads).
does wasmStreaming help with background compilation of wasm in not-focused tab? When user waiting for downloading of game and move to next browser TAB… in checked versions (5.6, 2017) I see what the game is blocked after download is complete until the tab is focused (in runInBackground too) and when it’s focused - the compilation of wasm is started and need to wait + few seconds.
It’s also critical to us due to another download routine after the unity webgl is instantiated. Now if the game is blocked on instantiation/init in this process “preloader 1” → “webgl init” → “preloader 2”, a user can’t move to next tab, and return with completed download of “preloader 2”, but must focus when “preloader 1” (unityweb) is complete, then wait a few seconds for “webgl init” and then wait for (or un-focus another time) “preloader 2” for special files (not unityweb).
I think it will be the same in the case of Asset Bundes as it’s start download after “webgl init”
Hello! Any chance we will see a multithreading for custom jobs? For example I have garbage-free jobs system for our project. And it’s work on PC and Android. But we are waiting for multithreading support in WebGL for instantiate 2-3-4 Threads and assign jobs to it. Our jobs is custom calculations, not unity engine related.
There are SharedArrayBuffer exist in 2018 year in the Chrome and Firefox.
p.s. Can I use custom threads from native JS in browser and ping-pong data between unity-heap and JS-thread, without need GC from unity? If custom-multithreading is in far future - the JS may be the case for our project for make a threads. But I think it will be difficult to make calculations in JS-side as current inmplementation in C#.
Will i be able both download an image from a server and place it on a gameobject, all on a separate thread?
Im having problems with that now, it causes the game to stutter a lot when doing that, the problem is im downloading up to 30 images from a server at random times in the game, causing the game to freeze while doing that. It make the game look like its crashing or has a bug.
Being able to do that on a separate thread would make it smooth.
I’m using Unity 2019.1.0a14 and I can’t find threadsSupport in PlayerSettings.WebGL.
Also, I tried web build and got this issue on Chrome (Version 73.0.3674.0 (Official Build) canary (64-bit)) and Firefox (65.0b11 (64-bit))
To use dlopen, you need to use Emscripten's linking support, see https://github.com/kripken/emscripten/wiki/Linking UnityLoader.js:4 To use dlopen, you need to use Emscripten's linking support, see https://github.com/kripken/emscripten/wiki/Linking UnityLoader.js:3 Invoking error handler due to Uncaught abort("To use dlopen, you need to use Emscripten's linking support, see https://github.com/kripken/emscripten/wiki/Linking") at Error at jsStackTrace (tripleone_1.1.7.wasm.framework.unityweb:8:22313) at stackTrace [Object.stackTrace] (tripleone_1.1.7.wasm.framework.unityweb:8:22484) at Object.onAbort (http://localhost:9090/Build/UnityLoader.js:4:11065) at abort (tripleone_1.1.7.wasm.framework.unityweb:8:507744) at _dlopen (tripleone_1.1.7.wasm.framework.unityweb:8:180788) at wasm-function[64724]:116 at wasm-function[64320]:205 at wasm-function[36934]:80 at wasm-function[36933]:43 at wasm-function[65668]:16 at dynCall_iii [Object.dynCall_iii] (tripleone_1.1.7.wasm.framework.unityweb:8:478993) at invoke_iii (tripleone_1.1.7.wasm.framework.unityweb:8:347776) at wasm-function[36932]:120 at wasm-function[65699]:15 at dynCall_vi [Object.dynCall_vi] (tripleone_1.1.7.wasm.framework.unityweb:8:492578) at invoke_vi (tripleone_1.1.7.wasm.framework.unityweb:8:373754) at wasm-function[36930]:66 at wasm-function[36929]:43 at wasm-function[46947]:3 at wasm-function[65660]:13 at dynCall_ii [Object.dynCall_ii] (tripleone_1.1.7.wasm.framework.unityweb:8:477241) at invoke_ii (tripleone_1.1.7.wasm.framework.unityweb:8:344582) at wasm-function[46949]:169 at wasm-function[65660]:13 at dynCall_ii [Object.dynCall_ii] (tripleone_1.1.7.wasm.framework.unityweb:8:477241) at invoke_ii (tripleone_1.1.7.wasm.framework.unityweb:8:344582) at wasm-function[36962]:326 at wasm-function[41858]:315 at wasm-function[38297]:105 at wasm-function[26367]:48 at wasm-function[65673]:18 at dynCall_iiii [Object.dynCall_iiii] (tripleone_1.1.7.wasm.framework.unityweb:8:480290) at invoke_iiii (tripleone_1.1.7.wasm.framework.unityweb:8:350150) at wasm-function[38312]:801 at wasm-function[65705]:17 at dynCall_vii [Object.dynCall_vii] (tripleone_1.1.7.wasm.framework.unityweb:8:495166) at invoke_vii (tripleone_1.1.7.wasm.framework.unityweb:8:378335) at wasm-function[29775]:162 at wasm-function[38308]:497 at wasm-function[37996]:94 at wasm-function[38282]:62 at wasm-function[38281]:45 at wasm-function[65675]:20 at dynCall_iiiii [Object.dynCall_iiiii] (tripleone_1.1.7.wasm.framework.unityweb:8:481284) at invoke_iiiii (tripleone_1.1.7.wasm.framework.unityweb:8:352011) at wasm-function[38283]:852 at wasm-function[65705]:17 at dynCall_vii [Object.dynCall_vii] (tripleone_1.1.7.wasm.framework.unityweb:8:495166) at invoke_vii (tripleone_1.1.7.wasm.framework.unityweb:8:378335) at wasm-function[29773]:162
Thanks!
I added that file under Assets/Editor and could use threadsSupport field in WebGL player settings,
But still the same error with webgl build. I think it’s because of C# Threading that we are using.
So is c# multi-threading not available in 2019.1.0a14 yet? When will it be available?
As we are using nakama game server client for unity - https://github.com/heroiclabs/nakama-dotnet.
and for webgl build we are running into some issues because of multi-threading.
I’ve discussed with their team too about this but they are dependent on c# threading support in webgl builds for Unity.
I’ll open a new forum thread for the error stacktrace.
@Marco-Trivellato
Our game server is entirely a separate standalone application, It’s just that their client library for Unity that we use to interact with the server is written in c# and uses threads. It works great for android and iOS builds but breaks with web.
So, our hope to make Unity WebGL build work is to get c# threads to work.
@Samhayne Did you used C#'s System.Threading ??
I’m just asking to know whether you used C# threading or one of the Unity features that internally uses threading.
On mac there are python issues python has no access rights emscripten has no access rights and on windows
Unity.IL2CPP.Building.BuilderFailedException: In file included from C:\workspace\unity\old\Temp\StagingArea\Data\il2cppOutput\mscorlib17.cpp:20:
Would be better to bundle a python version for mac that is rocket solid.
For me both platforms are failing with b9 build. I think it starts with the new emscripten version. Any suggestions?
