2019.1

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

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

2 Likes

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: Unity Issue Tracker - RectMask2D stops masking, when it's child has a child with Mask and 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:
4443697--406858--upload_2019-4-18_18-58-30.png

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

4 Likes

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.
1 Like

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

2 Likes

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?

yeah, that is a bug.

2 Likes

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?