Comments on The future of browser game graphics


Firefox on Linux supports WebGL. However, it isn’t very secure or stable; it’s pretty easy for an errant shader to bring the whole browser down, for example.

Even worse, on Mac OS X, an errant shader can cause a kernel panic, so.

Making shaders safer requires a lot more compromises in the entire stack, including better graphics drivers and which imposes cycle-time limits for shader execution, and it’s not a very easy problem to solve. Static code analysis can also only get you so far; trying to solve the problem of whether a shader halts is just as impossible as trying to solve the problem of whether any other program halts.

Not to mention the possibility that buffer overruns are found in various graphics drivers; drivers tend to be written under the assumption that the programmer knows what they’re doing and if the code is being run that it’s inherently trustable. In a browser-based environment, that goes completely out the window.

As much as I like their decision to go with GLSL from a programming standpoint, from an everything-else standpoint they really should have gone with some other shader specification mechanism. Everything else in the WebGL stack can be made secure or at least validated, but GLSL compiles directly to untrusted, unmanaged code that’s run by physical hardware, in a place that is completely out of the browser’s control.

-- fluffy 2017-10-05 07:36 UTC

Oh, and regarding your bullet points:

1. Unity3D’s plugin isn’t supported on Linux either (also it doesn’t solve the secure shader problem with WebGL)

2. Pure Java is terrible for mobile, mostly due to issues with Oracle’s licensing. (Android’s programmed in Java-the-language but the actual VM has nothing to do with Oracle’s; you can’t run an arbitrary .jar on an Android device without installing a bytecode VM, and that runs terribly)

3. Software rendering really sucks for mobile, where GPUs can do a lot more work with special-purpose circuitry that takes less power than implementing it in software. One of the most basic operations in graphics (linear interpolation) requires a lot of work from a general-purpose CPU, but with dedicated circuitry in a GPU it can do it faster with less power. Also GPUs can do some clever stuff to make less work for themselves, in ways that are difficult to implement in software (not to mention a lot less likely for a novice programmer to do); look at how PowerVR implements its depth testing, for example. (Hint: It’s not a z-buffer.)

-- fluffy 2017-10-05 07:36 UTC

Um, fluffy… I wasn’t talking out of my ass when I wrote that no browser seems to support WebGL on Linux. I tried. With the official nVidia driver, I might add.

That said, thanks for explaining the security issue with shaders; that’s exactly what I was talking about, but didn’t want to go into details.

As for the power issues on mobile devices, they didn’t stop manufacturers from putting Flash on many of them. If that’s not a resource hog, I don’t know what is.

-- Felix 2017-10-05 07:37 UTC

Funny, the latest Firefox (x64) on my Ubuntu 12.04 system supports WebGL just fine, using the Intel graphics driver. Maybe you have to get a specific build of it or something, or maybe Ubuntu configures it with WebGL by default. There are a lot of variables to worry about, though.

I’m also pretty sure that Chrome does as well, although the last time I checked you had to explicitly enable it with a command-line option.

-- fluffy 2017-10-05 07:38 UTC

Also, while it is true that Adobe did release an Android version of Flash, basically nobody uses it — because it performs like ass and kills your battery.

-- fluffy 2017-10-05 07:38 UTC

No, I mean devices much weaker than that, such as my old MP3 player (and my E51, but that one’s already quite powerful).

-- Felix 2017-10-05 07:38 UTC

Certain subsets of Flash can be used in a mobile-friendly way, sure, especially if you set the graphical quality to low or medium. There are also embedded Flash-like environments (such as by Hooked Wireless) that translate the performance-killing graphical primitives into GPU- or low-spec-CPU-friendly ones, but they only support limited subsets of the runtime.

When it comes down to it, the parts of Flash that work well for mobile are basically the exact same parts that you get in HTML5 Canvas instead (limited drawing primitives and JITted ECMAscript).

Oh, and another performance/battery killer on Adobe’s Flash stack is its floating-point-based MP3 player. Presumably your MP3 player provided a hardware CODEC instead. 🙂

-- fluffy 2017-10-05 07:39 UTC

So it does, but I thought it was more because the CPU in a media player is typically weak, and you need a Pentium I equivalent at the very least to decode MP3s in software in real time.

And the Canvas API is all you need to do a lot of nice tricks. Which is exactly the point I’m trying to make as of late. 🙂

-- Felix 2017-10-05 07:39 UTC

Speaking of VRML, the whole Unity/WebGL thing was previously done (on Windows, at least) with WildTangent. i.e. hardware-accelerated 3d in the browser and you could write decent 3d games with JavaScript. I’m under the impression that WildTangent (erroneously/unfairly?) began to be perceived as malware and thus went out of fashion and became a distant memory.

-- Alan 2017-10-05 07:39 UTC