It's an idea tried and failed many times over (GPU hosted games in the cloud, OnLive, GaiKai, etc). The round-trip lag from the time you press a button until the time you see a change on the screen is just unacceptable for most twitch oriented games. The JS/Web implementation doesn't change anything about the fundamentals. I don't know why Mozilla is bothering with this approach vs the Emscript/Asm.js which would fair much better (but still not likely to succeed for AAA games)<p>You have people complaining about touch-lag on Android devices, which is on the order of 100ms, and you're telling me you're going to send a packet with a controller movement, render a frame, compress a frame, ship it back, and display it with something <100ms? The demo shown is a non-interactive cut-scene, so no one's going to notice the input lag. OnLive, when latency was actually measured, came out around 150ms, totally unacceptable.<p>Th true test would be running something like CoD, BF4, or a SF2 tournament and get pro gamers to evaluate the system.<p>The AAA titles are never going to be run this like economically. I'm playing Battlefield 4 right now, a huge huge game that brings my current PC rig to its knees. Why would anyone want to suffer this with 150ms lag and compression artifacts?