Brandon Jones

> It's not the first time someone's had environments (sans game) running, see for example Quake3 (http://media.tojicode.com/q3bsp/).

Quake 3 was released in 1999. Unreal Engine 3 is a current and top-of-the-line engine for AAA games.

> There was a time when Sun was marketing Java and pushing heavily on this idea that it would one day meet or beat C/C++ performance, but it never quite got there after 2 decades (yes, in some circumstances it comes close, in others, it fairs badly).

This is totally different. asm.js is just a backwards compatible encoding of a different, much lower-level language. In fact, that lower-level language is in direct correspondence with the intermediate representation of a production-quality C++ compiler (clang)!

Sun never tried something like asm.js for Java; rather they claimed that the full language would be as fast as C and C++.

> memory, SIMD, layout, threading

asm.js gives full control over memory and full control over layout, with the exception of stuff like mmap() and mprotect() and self-modifying code.

SIMD is something that RiverTrail/ParallelArray can do. It should be added to asm.js.

As for threading, I'm personally in favor of an extension to allow a typed array to be shared between workers, races and all, with some primitives to allow synchronization. Not everybody is OK with this, but I personally believe we aren't likely to get to native performance without it. (Again, this is just my personal opinion; many disagree on whether…

(on Scaling) Games usually scaled based on GPU power, but not so much on the core game logic, AI, etc. Any CPU processing that actually affects gameplay outcome (e.g. collision detection) cannot really be disabled and scaled. Otherwise, you end up playing a different game based on your machine, not a game that only looks uglier or plays choppy.

This demo looks great, but all I see are environments rendered. I didn't see any firefights between lots of player models or vehicles, no Havok/PhysX/Bullet, I didn't see any enemy AI running. I did see some frame rate hitching. It's not the first time someone's had environments (sans game) running, see for example Quake3 (http://media.tojicode.com/q3bsp/). Even the Rage Engine got an environment renderer ported to the Web.

There's a danger in overselling stuff. When I helped port Quake2 to the Web (GwtQuake), I didn't have any illusions about being able to run something like Crysis or Call of Duty series in the the browser in JS, or consume the same resource requirements. I mean, I thought it would be possible, but a hideous waste of system resources.

There was a time when Sun was marketing Java and pushing heavily on this idea that it would one day meet or beat C/C++ performance, but it never quite got there after 2 decades (yes, in some circumstances it comes close, in others, it fairs badly). I see the same parallels today, pushing the idea that a dynamically typed language with some extra 'hints' is going to match a language…

http://www.khronos.org/files/webgl/webgl-reference-card-1_0.pdf
http://www.khronos.org/files/opengles3-quick-reference-card.pdf

Look at the sources to http://media.tojicode.com/q3bsp/

Notice the clunky transitions between Javascript and some degenerate form of C where everything is a member function of some hairy stateful singleton global object.

Oh, and all that matrix math isn't part of WebGL, the API neither provides graphics-specific utility functions nor general-purpose math operations. You have to roll it yourself in Javascript. You know, the way you have to write your own layout engine to write a 2d webpage?

This is all before we even get to the shader, where they just threw up their hands and said, "fuck it, let's have them send GLSL source as a wire protocol"

Also, security problems, weird device whitelist/blacklist, Microsoft's reasonable "hell no" stance, etc. Taking WebGL seriously is sucking the air out of the room and preventing progress on satisfying the demand for sane 3d on the web.

Thinking about your comment made me realize that the lackluster performance often seen in WebGL pages has very little to do with overhead in WebGL itself, and a lot to do with the application developer's failure to optimize for performance.

Native Quake III on a Pentium 4-era system was much smoother than most of the WebGL stuff I see on a modern system, but the fact that a WebGL demo [1] of a subset of Quake III is very smooth seems to support this idea.

You make a lot of good points about the difficulties that the low-level nature of graphics programming present to standardization. I agree that there probably isn't necessarily an easy solution to this which doesn't unnecessarily restrict the space of possibilities in the name of performance or interoperability.

[1] http://media.tojicode.com/q3bsp/

One of my all-time favorite quotes on browsers, from http://blog.tojicode.com/2013/08/holistic-webgl.html

"Have you actually seen how people use web browsers? Honestly it's kind of horrifying. It's not unusual for people to have 100+ tabs open across several different browser windows in a session that's been running continuously since sometime in the late 90s."

I was one of those 1k+ tabs people until recently, when I just admitted I'm not going back to read any of this stuff. Considering Chrome team has finite resources I'm glad they spend it on use cases resolving around actually browsing things over just keeping them unread forever.

I like the concept of the web jumping to the next device/interface.

After the desktop, after mobile, there might be VR in a few years. The pattern will surely repeat itself, with faster experiences for native, compiled applications, but I wonder if the "good enough" will come quicker thanks to webgl.

Looking forward to what Vladimir Vukićević and Josh Carpenter ([0] from Mozilla) and Brandon Jones ([1] from the Chrome team) are doing!

[0]: http://www.roadtovr.com/firefox-gets-vr-api-browser-based-virtual-reality-early-developer-examples-emerge/

[1]: http://blog.tojicode.com/2014/07/bringing-vr-to-chrome.html