Search Unity

Chrome / Firefox HTML elements unresponsive while loading and initializing.

Discussion in 'WebGL' started by GwendolinFrost, Oct 13, 2017.

  1. GwendolinFrost

    GwendolinFrost

    Joined:
    Oct 13, 2017
    Posts:
    2
    Hello.

    I've been trying to replace existing Three.js content and port it to Unity.
    The main problem I ran into however is that while loading and initializing the gameInstance, the elements on the page get unresponsive. For instance if there is a slider, there are 2 major lags where you can not interact with the UI for 1-3 seconds, which feels kind of bad as a user because you don't know whats going on. Even gifs stop playing during that time.

    One option would be to put a button on the page that triggers it all so you have a "reason" for the unresponsiveness (click->load), but since this content should be loaded with the page I'd like to avoid that at all cost.

    I tried using "noInitialRun": true and trigger callMain from a button like suggested here on the forum to smooth load before executing, but it turned out there is one lag while loading and another one right after gameInstance.Module['callMain'](); is called. With Chrome it is 10x more noticeable than Firefox even when using Canary.

    WASM is doing slightly better than ASM on loading times but its no real difference in responsiveness. Gzip compression is enabled and working.

    Is there any way around this unresponsiveness?

    Thanks in advance,
    Gwendolin
     
  2. sirrus

    sirrus

    Joined:
    Jun 10, 2012
    Posts:
    250
    Welcome to my world :(

    This has been our ongoing struggle with Unity WebGL since it's release.

    We have found recently that WASM compilation times (which Chrome still can't truly handle without causing major page stall) vary for our project anywhere from 5 to 60s depending on the player's machine. Even if download times - due to our optimizations to reduce build file sizes - are a fraction of that.

    There is no effective way to show progress if the progress indicator halts for >10s because the project is compiling.
     
  3. kognito1

    kognito1

    Joined:
    Apr 7, 2015
    Posts:
    328
    We just fake it. So for us our binary is just code and the art assets are split across 100 or so asset bundles. The first half of the loading bar is completely fake. We increase the loading bar based on time (and the longer it's been the smaller the interval we increase the loading bar by). When the binary is finally fully loaded we "jump" to the midpoint and then increase the bar by the number of asset bundles you've finished downloaded divided by the number of total asset bundles.

    Not perfect obviously, but works well in practice.
     
  4. sirrus

    sirrus

    Joined:
    Jun 10, 2012
    Posts:
    250
    We fake it as well but since the actual page rendering halts, the fake "progress" halts as well. As do animated GIFs and buffered videos. We've tried just about everything to indicate progress while the page 'halts'.

    This is *just* the binary build; our assetbundles are loaded separately once the unity engine is instantiated (another slight halt).
     
  5. kognito1

    kognito1

    Joined:
    Apr 7, 2015
    Posts:
    328
    I'm not sure what the "web people" do exactly or if the stall for us is so small that it's not noticeable, but doesn't seem to be a problem. How big your binary? Ours is 3.3mb (gzip'ed).
     
  6. GwendolinFrost

    GwendolinFrost

    Joined:
    Oct 13, 2017
    Posts:
    2
    Hi guys, thanks for the replies.

    I ran some additional tests too. I tried with a minimal build that has about 3.10mb gzipped and got the following stall seconds overall:
    Firefox 1-2 sec
    Canary 3-4 sec
    Chrome 4-5 sec

    What I noticed is that Firefox does not seem to have pre-initializing ui stalling when using noInitialRun while Chrome and Chrome Canary have a significant stall before and after. To me the Firefox stall time seems ok, but the Chrome loadup feels like begging for users to leave the site, its a very noticeable time of non interaction.

    I guess it highly depends on what kind of content it is used for. If the WebGL content is the hero object of the site I think I could live even with the Chrome times if nessecary, but as a side attraction on a page its hard to justify causing 4-5 seconds of stalling to the rest of the page.
    And that is on decent hardware, the 60 seconds reported by sirrus on lower end devices fighten me a little to be honest.

    Unfortunately my web-/emscriptenfu is not too strong. But I'd really love to know what exactly is blocking it, and if it would be theoretically possible to split the loading up into smaller chunks, and if that could even help in eliminating it. It feels odd to me that it would stall that much on such a small amount of data.
     
    Last edited: Oct 14, 2017
  7. sirrus

    sirrus

    Joined:
    Jun 10, 2012
    Posts:
    250
    The swath of compilation times shocked us. @GwendolinFrost, your 'stall' times match up with ours on local, decent machines so we were dismayed to see such longer times in production. With that said, in our case I'm hoping the actual stall is still a fraction of the overall compilation time but we are still confirming that. But anything over 5s is a major bail point.

    Our code binary is about 3.5MB (the data adds another 1.6MB). WASM, brotli compressed.
     
  8. kognito1

    kognito1

    Joined:
    Apr 7, 2015
    Posts:
    328
    Ours is 2.5mb with brotli compression, a decent amount less to parse and load. Is there anything you can strip (physics)? That'll give you the biggest reduction with respect to stalling.
     
  9. sirrus

    sirrus

    Joined:
    Jun 10, 2012
    Posts:
    250
    The largest components of our build are a loading screen texture, scripts and 1 or 2 plugins (that are still extremely small and necessary). We aren't using physics and have stripped out pretty much everything else.
     
  10. kognito1

    kognito1

    Joined:
    Apr 7, 2015
    Posts:
    328
    I suspect it's the plugins that are sinking you. :( 1MB of highly compressed code for plug-ins is...a lot.
     
  11. Marco-Trivellato

    Marco-Trivellato

    Unity Technologies

    Joined:
    Jul 9, 2013
    Posts:
    1,653
    Have you checked files.unity3d.com/build-report/ (after building for Unity WebGL), to see what's actually being included in your build?
     
  12. sirrus

    sirrus

    Joined:
    Jun 10, 2012
    Posts:
    250
    Marco, we use the Unity Build Report and another Build Report tool from the Asset Store. Both have slightly strange results.

    We are using colliders and terrain so there are actually some physics modules being used. It also says we are using IMGUI but we're not using OnGUI anywhere in our code base.

    Our other build report tool shows this:
    upload_2017-10-17_10-36-21.png

    Any idea why the Timeline DLL is included? We're not using it anywhere.

    The SharpZipLib DLL is about 150kb but the other external plugins are very small and shouldnt be contributing much to build size.
     
  13. kognito1

    kognito1

    Joined:
    Apr 7, 2015
    Posts:
    328
    Colliders = physx (all of physics) <---This is huge and your big bottleneck. Not saying you can work around this dependency, but if you can it will be a HUGE win.

    IMGUI = using input (event system). I complained again at Unite about this (false) dependency. :p Unity said sooner rather than later. We'll see. ;)

    Also use the link that Marco provided, it's extremely useful and IMO essential for WebGL (and will show you just how big physics is...).
     
  14. sirrus

    sirrus

    Joined:
    Jun 10, 2012
    Posts:
    250
    Yeah, I misspoke when I said "no physics" :confused: and the Unity tool shows a good breakdown of the modules that are used; none of which are feasible for us to remove at this point :(

    Didnt mean to hijack this thread... hopefully some of this helps the OP as well.
     
  15. Marco-Trivellato

    Marco-Trivellato

    Unity Technologies

    Joined:
    Jul 9, 2013
    Posts:
    1,653
    does Timeline show up in the build report web page?
     
  16. sirrus

    sirrus

    Joined:
    Jun 10, 2012
    Posts:
    250
    I don't see it anywhere. Perhaps that's a bug in this other Build Report tool?
     
  17. Marco-Trivellato

    Marco-Trivellato

    Unity Technologies

    Joined:
    Jul 9, 2013
    Posts:
    1,653
    probably not. If it's not used in the project, then Timeline symbols will be stripped.
     
unityunity