Search Unity

WebGL issues

Discussion in 'Web' started by insmo, Apr 17, 2015.

  1. insmo

    insmo

    Joined:
    Apr 17, 2015
    Posts:
    12
    These are some issues we encountered during a week of Unity WebGL work.

    * Keyboard events bubble up to the window object. It's required to work around this by catching the event. This should probably documented or solved by default.

    * Module object is undocumented. This is required to be defined to load WebGL builds. If you do anything else than mess around on your local machine you need to reverse engineer this and figure out how things are loaded.

    * WebGL builds are loaded on the global namespace (window) and it's not obvious how to work around this. I've tried to wrap the JavaScript output into an anonymous function, but was unsuccessful in getting that to work. When you load a default WebGL build output in your browser 1000+ properties are added. It's not possible to run this on your website without random namespace clashes and the only semi-reliable solution seems to be to load your game inside an iframe (this comes with new issues and work, but it wont totally brake things).

    * Application.runInBackground = true does not work in the browser. This is a (will become) a complaint by developers using the WebGL build target, unless a solution is found. The general issue is that browsers will stop Unity runtime and setInterval minimal timer will increase to 1 sec for background tabs. We have a test where we write the frame count to console.log, when we switch the tab to background it stops. In a network game with Photon's networking WebSocket implementation switching tabs will disconnect the player.

    * Parsing large JavaScript files requires lots of memory. You can observe this in Jona's AngryBots example. On my computer I'm using ~3GB while loading the game, while when playing I only use ~2GB. We've found that in our game we currently need ~4GB while loading < 1GB while playing. On lower end machines with less RAM we can often run the game, but the user has to get past the loading JS step. On low end clients with not enough memory available this results in the system swapping out memory to disk and essentially freezing the browser. Addressing this loading issue imperative if Unity ever want's to reach the same penetration percentage as what they have had with their WebPlayer platform.