2019.1

Finally a good jump is coming.
Thank you for the informations.

 

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).

 

Once you implement the fallback to single-threaded version, will code written with ECS and job system still work on a single-threaded browser?

 

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.

 

"WebGL: Added UnityLoader.instantiateAsync() which returns a JS Promise"
Does it mean the whole page will not freezing anymore while loading game?

 

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.

 

Tried it out with our WebGL project... but it would freeze during startup with

Code (csharp):

1. Preallocating 1 workers for a pthread spawn pool.

as the last entry in the browser console.

Tried in Chrome and Firefox - both behaved the same - threading/shared memory are enabled in both.
Tried out memory sizes 512 and 2048.

Unity Version: 2019.1.0b4

The game would start fine when built with PlayerSettings.WebGL.threadsSupport = false.

 

@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.

 

@hindusingh: Hm... we're using Best HTTP in our WebGL project which is using System.Threading.

Here again the last error we get... eventually followed after some time by the block in yellow.

 

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?

 

Looks like there's some good progress on memory growth with pthread support, yay!

https://github.com/emscripten-core/emscripten/pull/8365

 

My game loads lots of textures from the server while its running displaying them at different spots in the game as the players walks close, but it keeps stuttering because 2018.1 loads the texture on the main thread, so i cant release my game.

Im wondering if 2019. has solved that?

 

Does new Unity WebGL suport change MemorySize and compile to old browsers (like Chrome 50)?
I can't find any reference for asm.js or MemorySize in PlayerSettings

My customer block any blowser update, so i must keep support asm.js.
Can i force compile with asm.js support (or both support, like in Unity 2018.3)?

 

I'm not 100% sure if this is still the case but I believe you can modify your ProjectSettings.asset directly in a text editor and make sure

webGLLinkerTarget 

is set to '2' (asm.js + wasm). I know memory growth has a performance impact on asm.js though so I'm not sure if it disables it or not.

 

Hi JJJohan, the modification of the ProjectSettings.asset not work... Does anyone have any tip on this? Like up here in comments I've need asm compilation as well.

 

Hi, we just updated to 2019.1 (from 2018.3) and we have issue with rectmask2d in webgl build. Rectmask2d stop masking. There is issue in tracker: https://issuetracker.unity3d.com/is...d-image-components-inside-the-rectmask2d-area
In 2018.3 for us helped workaround with "Shader.EnableKeyword("UNITY_UI_CLIP_RECT");", but now this workaround does not help.
Does anyone have any idea what can be done about it?
@Marco-Trivellato

*UPDATE. we have solved a problem. We have copied shader UI/Default and edited "multi_compile_local" to "multi_compile" in "UNITY_UI_CLIP_RECT". (in 2018.3 was multi_compile without "local" )

 

Sorry, I meant to say '2' not '3'! I just did a quick test and it appears to work. I also see 'Compile asm.js module' during build.

Output of an empty project WebGL build done from Unity 2019.1.0f2:


I'm in the same boat, unfortunately we have enterprise clients that have IT-preconfigured images that use ancient versions of Chrome so we'll need the asm.js fallback as well.

Basically:
0 = asm.js
1 = wasm (default)
2 = asm.js + wasm

 

Thanks a Lot!

 

Fellas who upgraded to 2019.1, can you tell a difference in terms of performance (loading then running) ?
Thanks

 

No additional perfomance in 2019.1. Maybe just a little...
because:
1. Multithreading dont support fallback to single thread browser, so it is useless today
2. instantiate async gave nothing (just control js promises)
3. wasm streaming compilation gave a little increase of instantiation wasm build. About 0.5 seconds (3 seconds vs 3.5)
4. The bug with memory leak was not fixed (although it was noted that it was fixed in 2019.1)
5. ASM build have a perfomance degradation

But we got a bunch of bugs:
1. Bug with alpha transparenty
2. Bug with rectmask2d
Maybe something else. We have not had time to test properly.

 

Thank you so much. We won't rush upgrading from 2018.2.

 

Early tests show pretty good results with streaming on slow devices (saved 25 seconds on our ancient android phone).

 

Ah but the streaming does not seem to get cached? It's getting downloaded every time, a bit of a trade-off...

 

We have cached .wasm. We have nginx for file distribution and for .wasm files we added mime.types "application/wasm" and encoding: gzip.
Does the streaming compilaton work with gzip in general? Because i have tested in chrome with slow 3G network emulation and had a freeze after the .wasm build has downloaded

 

Nice things, thanks for informing.

 

Is support for .Net threads something Unity is actively working on for webassembly builds?

 

What happened to HiDPI/Retina support?

 

Found that Unity added this update in unity 2019.1 release

WebGL: Added experimental multi-threading support.​

What does it mean? unity allowing to use threading namespace in webgl? or unity itself using threads internally ? Once i red that javascript doesn't allow thread i.e., unity can provide threading support? So what happened now?

 

I noticed 2019.1.1 came out, but even that hasn't fixed the previously reported PlayerPrefs issues that were fixed in 2019.2.0a13.

"WebGL: Fixed an issue with saving PlayerPrefs in WebGL. (1140820, 1145636)"

To me not being able to read/write saved games in one of the available platforms is a pretty big deal and should have been a priority - enough to block 2019.1, let alone 2019.1.1. Are we going to get a fix for this soon?

 

I hope you will get an answer, i have asked here https://forum.unity.com/threads/playerprefs-in-2019-1.665254/ already without any answer. Reported the March 26 and still the same.

 

Hello @Marco-Trivellato, does it mean that game object converted to entities and rendered with the Hybrid Renderer can't actually display in WebGL ? Cause I made a pong game fully with DOTS and the new input system (source here) and windows build are OK but WebGL build don't display any entities..

FYI I linked the console output of Chrome.

Code (CSharp):

1.  TypeError: Failed to execute 'send' on 'XMLHttpRequest': The provided ArrayBufferView value must not be shared.
2. _JS_WebRequest_Send @ 6d3d08fb-8c22-4ab9-8280-87fdb842e469:8
3. (anonymous) @ 6d3d08fb-8c22-4ab9-8280-87fdb842e469:8
4.  

 

That error is related to how POST web requests are handled when threads are enabled, there seems to be an issue open for it here: https://issuetracker.unity3d.com/issues/xmlhttprequest-fails-with-threading-enabled

As a workaround, you can patch the WebRequest.js file under the Unity install directory at Data/PlaybackEngines/WebGLSupport/BuildTools/lib/ or alternatively don't enable threads, at least until there's an official fix.

In regards to an actual patch, here's a quick edited WebRequest.js that simply copies the HEAPU8 data to a non-shared array (changes are on line 113). I'm not familiar enough with JS array code to know if there's a one-line copy so I just did an old-fashioned for-loop copy. Rest assured this should not result in memory leaks since it's a JavaScript array. Backup and replace the WebRequest.js in the path I mentioned before.

 

Thanks for the explaination. I use job systems so disabeling multithred is not an option in my understanding. I'll try your patch see if it solve this issue and if i finally can see my entities.

 

Sorry but after trying, it make the build fail. SO guess I'l have to stick with windows build for now.

 

FYI if you've been using the cachedhttprequest plugin for asset bundles, the latest versions of Unity 2019.1.x (although oddly not 2019.1.0?) have it included. It even seems to still work with the old logging flags. You'll need to remove the plugin version or UnityLoader.js will blow up (crash) on startup.

 

I have upgraded my project from unity 2018 to 2019.1.0. Previously it already have a plugin inside the asset folder. But now it unity 2019 i found that there is also a plugin folder outside unity with WebGLCachedXMLHttpRequest and WebGLCachedXHRExtensions. Now my question is, do i need to remove the inner plugin folder? or which one will be used?

 

We had to remove the inner plugin folder for the build to function.

 

Thanks, i tried to find some official information regarding this matter but unable to find. Can you provide the relevant link? And second thing is currently i am using both plugins and build working fine.

 

¯\_(ツ)_/¯ Our builds didn't work for us in 2019.1.3 until we removed the cachedhttprequest plug-in from our project. The caching still worked though even after we removed it.