Mozilla Hacks

Web Games Platform: Newest Developments

By Andre Vrignaud

Posted on March 1, 2017 in HTML and WebGL

In July of 2015 we announced our Games Technology Roadmap, and have been working on addressing those pain points as shared by developers.

Games are an important part of the web experience. Mozilla and other browser vendors have been working hard to find alternative paths that developers can migrate to. As we come to the end of plugins (Firefox 52) and many browsers planning to make Flash click-to-play during 2017-2018, we are working hard to complete the alternatives and insure they are viable. Many new features that will help improve the platform are arriving in the next few versions of Firefox, and we are seeing other browsers on a similar course.

We’ve been working closely with other browsers, tool makers, and game developers to test at scale, and promote universal availability of key technologies across all the major browsers. We have seen success with top Facebook titles such as Bubble Witch 3 Saga and Candy Crush Jelly Saga from King, and Top Eleven from Nordeus. There is still work to do to get full potential out of the platform, but today we wanted to provide a status update on what we’ve been working on and what you’ll see shipping in browsers in the near future. Whether you are using compiled code bases and/or JavaScript there’s a little bit here for everybody!

What We Heard

As we reached out to game developers, publishers, and browser makers we heard a common set of concerns and requests:

  • Developers wanted to improve their user experience. They have let us know they would like to see reduced code size, faster compile and load times, reduced memory usage, and improved performance to make it easier for users to engage.
    • WebAssembly is a significant leap forward in addressing all of these issues.
    • We recently announced that the four major browsers have reached a consensus on the stable initial version of the standard, enabling all browsers to start shipping WebAssembly.
    • Mozilla intends to release WebAssembly, the successor to asm.js, in Firefox 52 in March 2017.
  • Developers wanted to reach as many users as possible and would like to see more users be able to run WebGL content.
    • Targeted efforts have improved desktop WebGL success rates on non-Windows XP machines from 80% to 99%. We are also seeing a similar trend across other browsers. In addition, telemetry shows that desktop WebGL availability matches that of Flash on Firefox.
    • Developers wanted OpenGL ES3 features in WebGL 2, including new texture formats, and support for floating point texture filtering, rendering to multiple render targets, and MSAA multi-sampling.
    • WebGL 2 supports OpenGL ES3 features. WebGL 2 was released in Firefox 51 in January 2017, and other browsers are following suit.
  • Developers have asked for greater flexibility in allocating larger amounts of address space on 32-Bit systems to run bigger and more complex applications.
    • 32-Bit Out Of Memory (OOM) issues are often caused by a browser process being unable to allocate large blocks of memory due to address space fragmentation.
    • Firefox intends to ship a 32-Bit OOM solution in Firefox 53 in April 2017.
      We do not have similar challenges in 64-Bit versions of Firefox.
  • Developers would like greater information about the hardware Firefox users browse the web on to inform their development decisions.

Details

Standardizing and Shipping WebAssembly:

WebAssembly is an emerging standard whose goal is to define a safe, portable, size- and load-time efficient binary compiler target which offers near-native performance — a virtual CPU for the Web. WebAssembly is being developed in a W3C Community Group (CG) whose members include Mozilla, Microsoft, Google, and Apple.

WebAssembly can be considered the successor to asm.js, a Mozilla-pioneered project to push the limits of performance within the constraints of the existing JavaScript language. Although, asm.js now offers impressive performance in all browsers, as a new standard, WebAssembly removes incidental constraints, allowing engines to get ever-closer to native performance (while maintaining the same safety and security model as JavaScript). Preliminary measurements in Firefox show that, on average, WebAssembly brings realistic C/C++ workloads to run within 1.25× native speed, down from 1.38× with asm.js — a 9% improvement! Further speedups are anticipated as work continues on the whole pipeline. Dramatic 8× speedups have been observed for synthetic workloads that utilize new WebAssembly features like 64-bit integer arithmetic.

We recently announced that the WebAssembly Community Group had reached a consensus on the initial version of the standard. Interoperable implementations have landed in pre-release Firefox and Chrome channels, and are under development in Chakra and JavaScriptCore. Mozilla intends to release WebAssembly, the successor to asm.js, in Firefox 52 in March 2017.

Improving WebGL Success Rates:

We have been able to identify and address issues that impacted the availability of WebGL on Firefox. In particular, Firefox telemetry shows that we have reduced WebGL availability failures from over 20% in Firefox 47 to less than 8% in Firefox 50 across all machines. And targeted efforts have improved WebGL success rates on non-Windows XP machines from 80% to 99%. This is consistent with the level of improvement we have seen with other browsers.

Standardizing and Shipping WebGL/WebGL 2:

WebGL 2 is based on the OpenGL ES 3.0 specification, and offers new features, including 3D textures and 2D texture arrays, ESSL 3.0 (an advanced shading language), integer texture formats and vertex attributes, transform feedback, and uniform blocks for more efficient uploads. It also adds primitive restart, framebuffer blitting and invalidation, separable sampler objects, occlusion queries and pixel buffer objects. In addition, some optional WebGL 1 extensions are now part of the guaranteed core of WebGL 2, including multiple render targets, instanced drawing, depth and floating-point textures, and sRGB support. Also notable is support for the new ETC2 texture format which provides alpha support on a compressed texture and is supported on both desktop and mobile devices. Finally, improved garbage collection offers a smoother experience overall. WebGL 2 shipped in Firefox 51 in January 2017.

Addressing 32-Bit Out of Memory Issues (OOMs):

A consistent pain point for web developers using compiled code bases and asm.js is hitting out of memory conditions on 32-Bit browsers. By default, on Windows, Firefox is a 32-Bit application. This limits Firefox to being able to use (at most) 4 gigabytes of address space, which tends to become fragmented over time, and prevents a game’s ability to request a large enough allocation to successfully run.

To address this, we have proposed a new Large-Allocation header. This header tells the browser to make a best-effort attempt to load the document in an unfragmented content process, which should greatly decrease the OOM failure rate for top-level browsing contexts, even on bigger allocations. We aim to ensure that if the conditions for a cross-process navigation are met, web apps are able to reliably allocate a gigabyte of contiguous address space. It is our intention to ship this solution in Firefox 53.

An additional opportunity is to encourage users toward using a 64-Bit browser, which allows applications to use huge amounts of physical memory. This means that address space exhaustion (or OOMs) are basically impossible.

Today:

  • 72% of our Windows users are running 32-bit Firefox on 64-bit Windows. These users could switch to a 64-bit Firefox.
  • 25% are running 32-bit Firefox on 32-bit Windows. These users cannot switch to a 64-bit Firefox.
  • 3% are running 64-bit Firefox already.

As nearly three-quarters of Firefox users are running 32-bit Firefox on 64-bit Windows, there is a huge opportunity to improve the ability of those users to run large web apps by accelerating the shift to 64-bit. As such, per our 64-Bit plan of record, we are targeting August 2017 (Firefox 55) to change the Firefox installer to default to 64-bit for new installs on 64-bit Windows. Upgrading existing 32-bit Firefox users on 64-bit Windows to 64-bit Firefox will probably happen in October 2017 (Firefox 56).

Sharing information about the Firefox Hardware Audience:

Suppose you’re developing a sophisticated web game or application. You may have questions about what capabilities web users have access to on their systems, or how you can target the widest possible audience? To help address these questions we recently released the Firefox Hardware Report to help answer those questions and inform your development decisions.

On the site you’ll find a variety of data points showing what hardware and OSes Firefox web users are using on the web, and trends over time. This includes CPU vendors, cores, and speeds; system memory; GPU vendors, models, and display resolution; Operating System architecture and market share; browser architecture share, and finally, Flash plugin availability.

In Conclusion

Our focus is now on landing all of the above improvements in the coming months. We wish to extend our gratitude to the game developers, engine providers, and other browsers’ engine teams who have worked so long on this technology. It’s been a massive effort, and we all collectively could not have done it without your help and feedback. Thank you!

About Andre Vrignaud

Andre Vrignaud is the Head of Platform Strategy for Mozilla’s Mixed Reality Program, where he guides the strategy for Mozilla's efforts to enable an open, sustainable 3D web and ecosystem. With a side of net neutrality and privacy advocacy.

More articles by Andre Vrignaud…

5 comments

  1. Pino

    I’m part of the 1% that can’t get WebGL. Last I checked, Intel GMA (pre-HD Graphics) provided only OpenGL 1.4, whereas WebGL requires OpenGL 2 or later. This means 10″ laptops such as my Dell Inspiron mini 1012 (which runs 64-bit Xubuntu 16.04) can run Flash but not WebGL. What’s the solution other than to buy a newer (and bulkier) computer?

    March 2nd, 2017 at 08:44

  2. voracity

    I know you all have very good intentions, so I feel bad saying the following, but I’m predicting that WebAssembly will be the single worst thing to happen to the web in its history.

    The consequences will take time to play out — perhaps a decade, so if everything looks OK in 2027, I’ll very happily admit I was wrong and was being very pessimistic.

    The web has never had universally-supported bytecode that works out-of-the-box before. Ever. (Flash was as close as we got, and that was an eternity away from universal.) With bytecode, obfuscation is the default and even with text mappings, the programmer’s intent is lost. It’s not a question of what is possible now with JavaScript versus what will be possible with WebAssembly. (You can do the same things in both — which is why WebAssembly is especially bothersome.) It’s a question of what is *encouraged*.

    My prediction for how things will play out is as follows: The initial release and support in major browsers will be accompanied by a flurry of demos and excitement. The excitement will settle down fairly quickly, as most people realise/accept JavaScript is still more convenient for the vast majority of things people want to do and WebAssembly (like any new tech) will initially be clunky to target. Things will proceed mostly as they have been. However, performance-sensitive groups will begin developing WebAssembly based products and (most importantly) libraries. They will also develop toolchains and frameworks that make WebAssembly development very simple, and these will likely work on the server (e.g. with a node.wa) and on the client (i.e. be isomorphic). A wide group of developers who previously focused exclusively on desktop development will find that web deployments are now just a compile-click away for them. They will find they don’t have to learn any JavaScript, HTML or CSS *at all* and can use whatever their own pet language is with just as good effect.

    This initial stuff won’t feel like the web. Those developers either won’t care or will see that as an advantage. More people will want to use their own pet language for web development, and almost *none* of these people are going to bother providing text maps, particularly ones that preserve programmer intent. Large shops will especially enjoy this new approach. They won’t care at all about the openness problems that a compile-to-gibberish approach creates — rather, obfuscation holds at least incidental advantages for them.

    The real turning point will occur once some group creates a WebAssembly toolchain for website development with wide appeal. Perhaps a CMS of some sort, or something that creates mobile-app websites (which currently have no view source by default anyway). The selling point will specifically be that it’s faster than anything else out there (whether relevantly true or not). At that point, people will begin using WebAssembly *indirectly* because it’s the easiest option, not because they made a conscious decision to make a WebAssembly-based site. And it’s a fully-endorsed “open” standards-based approach, so why not?

    (I should also point out that the intense pressure that has existed to Make JavaScript Fast will diminish if WebAssembly takes off, which creates a negative feedback cycle that makes things all the worse.)

    At that point, Mozilla will almost certainly realise the mistake it has made (I don’t think Google/Apple/Microsoft will care), and (if it still has clout in 5-10 years time) scramble to either promote the more open existing alternative or aim to create a more open toolchain.

    I can only hope that, when that time comes, Mozilla and the broader open source movement knows what to do.

    I should note: The most positive case for WebAssembly would be one in which only the most performance-sensitive code makes use of it. For real applications, this would be in exceptionally unusual circumstances. I write a reasonable amount of code which could be considered performance sensitive, and even there JavaScript works incredibly well (particularly with workers — although I’m eagerly awaiting WebGL compute shaders). In many cases, even standard CPython works well — and that’s because the algorithm/design choices are almost always much more important to performance than instruction speed.

    Anyway, I believe the outcome in which WebAssembly is restricted to performance-sensitive code has the lowest probability of all the possible outcomes, but is the best possible outcome. It lags well behind WebAssembly simply disappearing as a momentary curiosity, and what I unfortunately consider to be the most probable case that I outlined above.

    March 3rd, 2017 at 06:05

    1. Luke Wagner

      The ability to compile to the web has existed for at least a decade, as you’ve argued before with asm.js. And before asm.js, there were minifiers, which are, by now, common practice and very aggressive. Adding canvas 2D and 3D also added risk that everyone decides to render everything from scratch, treating the web as a big framebuffer (and indeed people have tried). So WebAssembly itself will not determine whether everyone switches to some opaque system. Also, JavaScript is still the one “blessed” (builtin, highly optimized) high-level language of the web and the need for scripting in applications won’t go away.

      March 8th, 2017 at 09:04

      1. voracity

        Thanks for pointing me to that old post and comment. It’s evidence that my concerns, however (un)warranted, are at least consistent over time. :)

        Canvas (or some equivalent emulation of it, like tables of 1px cells) is simply required for certain things. But while canvases are an ever-present risk, HTML is *vastly* more convenient for documents and even app interfaces, and difficult to replicate well. I would, however, argue that canvas has stymied the proper adoption and optimisation of SVG for vector graphics. I believe that’s improving with time as comparative SVG performance improves.

        Minification and (particularly) asm.js are currently used sparingly, and much like a world-wide JIT, mostly just for hot code (i.e. libraries). I believe (without prejudice) that’s because they are viewed as hacks. When asm.js first came out, many of the comments I recall reading included complaints (however misguided) that the end result was still just JavaScript. Most (non-JavaScript) people wanted ‘proper’ bytecode — and now they have it. Not only is it a first-class web citizen, Mozilla (and presumably others, soon enough) are actively advertising it as *faster* (=better) than JavaScript. If the right toolchains are developed (which may themselves be browser-based AND not open), the convenience and perceived-openness of WebAssembly may not differ from JavaScript. This is a lot of risk for how much gain exactly?

        The horse has bolted and its too late to close the gate, so I don’t hope or expect to persuade anyone that there may be a big problem here. At this point, I’m just making a prediction (and doing it openly) in the hope that if the prediction turns out true, there was at least some warning.

        March 10th, 2017 at 05:50

  3. diarec

    thank you so much mozilla

    March 4th, 2017 at 07:53

Comments are closed for this article.