Mozilla is Unlocking the Power of the Web as a Platform for Gaming blog posting tells that Mozilla is advancing the Web as the platform for high-end game development. Mozilla was able to recently worked hard to prove that the Web is capable of being a compelling gaming platform. With Mozilla’s latest innovations in JavaScript, Mozilla promises that game developers and publishers can now take advantage of fast performance that rivals native: Mozilla has been able to bring Epic’s Unreal Engine 3 to the Web.
Also WebRTC is getting great press lately for it’s amazing applications in voice and video communication. But did you know that WebRTC also has support for peer-to-peer data that can be used for gaming? Another communications method worth to check out is Websocket.
2 Comments
Tomi says:
IE11 To Support WebGL
http://tech.slashdot.org/story/13/04/02/2127205/ie11-to-support-webgl
“The biggest problem with IE10 as far as modern web apps go is its lack of WebGL support. Now we have strong evidence that IE11 will support WebGL. A leaked build of Windows ‘Blue,’ aka Windows 8.1, also contained an early version of IE11.”
Tomi Engdahl says:
Surprise! Mozilla can produce near-native performance on the Web
We put Mozilla’s JavaScript subset—asm.js—to the test.
http://arstechnica.com/information-technology/2013/05/native-level-performance-on-the-web-a-brief-examination-of-asm-js/
In a bid to make JavaScript run ever faster, Mozilla has developed asm.js. It’s a limited, stripped down subset of JavaScript that the company claims will offer performance that’s within a factor of two of native—good enough to use the browser for almost any application. Can JavaScript really start to rival native code performance? We’ve been taking a closer look.
JavaScript performance became a big deal in 2008.
In JavaScript, the way an object is meant to behave can change at more or less any time. A JIT engine could produce executable code to make an object behave one way, and then that object could be modified to invalidate the executable code. This means that the executable code has to be quite conservative to guard against this kind of modification.
Browser developers are, therefore, in a frustrating position. They want scripting engines that are faster to enable the browser to be used for a wider range of applications, but their efforts to improve performance are hamstrung by JavaScript itself. The language simply isn’t designed for high performance optimization.
This has all led to a number of efforts to change JavaScript itself. The first notable one is Google Dart.
Mozilla proposed an alternative. Rather than using an entirely new language, Mozilla defines a strict subset of JavaScript that it calls asm.js. The asm.js subset of JavaScript is very limited. It eschews, for example, JavaScript’s object-oriented constructs. As a result, it also eschews many of JavaScript’s hard-to-optimize dynamic capabilities.
This representation is much lower level than that found in traditional JavaScript programs, but it comes with an important constraint: it’s nonetheless still JavaScript.
asm.js programs already run in any browser. They’re just JavaScript programs, albeit weird JavaScript programs that don’t look like anything that a human would ever produce.
Browsers that recognize and have explicit support for asm.js can, however, take advantage of this knowledge to perform better optimization.
Mozilla doesn’t really intend for developers to write asm.js programs directly, however. Instead, the idea is that compilers use asm.js as the target, with programs themselves written in some other language.
That language is typically C or C++, and the compiler used to produce asm.js programs is another Mozilla project: Emscripten. Emscripten is a compiler based on the LLVM compiler infrastructure and the Clang C/C++ front-end. The Clang compiler reads C and C++ source code and produces an intermediate platform-independent assembler-like output called LLVM Intermediate Representation. LLVM optimizes the LLVM IR. LLVM IR is then fed into a backend code generator—the part that actually produces executable code. Traditionally, this code generator would emit x86 code. With Emscripten, it’s used to produce JavaScript.
Emscripten can be used in two modes. It can produce regular JavaScript and it can produce asm.js JavaScript.
An annoying development model
The JavaScript programs that Emscripten produces are huge. The binary-tree test, for example, results in a 16,896 byte native code executable. Its JavaScript counterparts are 379,784 bytes for regular JavaScript and 667,207 bytes for asm.js. Aside from the download implications this would have (though they can be mitigated through HTTP compression), these are simply huge JavaScript files. It turns out that most browsers aren’t really built for this kind of thing. Try to use your browser’s built-in debugging tools (whether Firefox, Chrome, or Internet Explorer) and you’ll find that they get awfully slow, to the point of being unusable.
But maybe that doesn’t matter because you wouldn’t really want to debug the JavaScript anyway. The JavaScript emitted by Emscripten is of a comparable level of abstraction to native assembly code.
A technique for addressing this, at least in part, is being developed. Source Maps should allow JavaScript debuggers to correlate between the compiled source and the thing that generated it. However, the debugging experience still, in practice, leaves an awful lot to be desired. Native code debuggers are complex and capable things, allowing easy transitions between source and assembly view, step-by-step execution with both source and assembly granularity, structured views of in-memory data, and much more besides. JavaScript debuggers are generally less mature, and asm.js makes this immaturity more acute.
Presently, your best bet is to debug native code using native debugging tools and hope that the Emscripten compilation works as it should.
Amazingly, asm.js actually works
asm.js works. It was surprising. We expected better-than-JavaScript performance, but we thought that Mozilla must have been cooking the books somehow with its claims of “within 2× native performance.” With some provisos around multithreading and SIMD code, the company was telling the truth. It really is that fast, and it can be very close to native performance.
In spite of that, it still may not be fast enough.
asm.js may fall a bit short of delivering truly native performance when compared to native code—but it might yet be valuable as a way of beating JavaScript itself.