Native Client (Google's NaCl)

I had an interesting discussion with someone a few days ago and he said something along the lines of, “Today’s marketplace needs exponential growth to survive financially. High-end platforms have began to fail in this area, so solutions to new problems need to be scalable downwards to accomodate for lower-end platforms.”

In the context of this post, I think that web platforms will become a nice showcase for demo-like stuff in the near future. Once it becomes more accessible, we’ll have demos that while not quite keeping up in technical regards with PC demos nowadays, could possibly start emulating the style and flair of demos that were popular in the late 90′s/early 2000′s. With similar platform capabilities, I think we’ll see some really kickass web stuff in the next couple of years.

</rant> :)

As it should be :)

Considering that any fragment shader that contains an infinite loop can deadlock my machine, I’m still far from at the point where I’d want random Joe Schmoe to be able to feed OpenGL commands to my machine over the interwebs.

This is a problem both for NaCl (if OpenGL gets included) and WebGL. The reason is that security hasn’t traditionally been a big focus in desktop graphics driver development.

• This reply was modified 269 days ago by  Erik “kusma” Faye-Lund.

Niels:

Sure, just try this fragment program:

uniform int inc;
void main(void)
{
gl_FragColor = vec4(0.0);
for (int i = 0; i < 3; i += inc) {
gl_FragColor.r += 1.0 / 3.0;
}
}

If I leave the “inc” uniform at the default value of 0, this hangs my GPU.

Luckily, loops that cannot be statically unrolled is illegal in ESSL, which is the shading language used in OpenGL ES 2.0 (and hence also WebGL), so this particular shader is invalid. But Firefox has a setting “webgl.prefer-native-gl” which as far as I understand feeds code directly to the target GLSL-compiler when enabled. And I’ve seen WebGL evangelists out there encourage people to set it to true.

• This reply was modified 268 days ago by  Bent Stamnes.

Actually, ESSL allows dynamic flow control in the vertex shader, where this issue might also be present. But I haven’t really tested that, and I don’t feel like a potential reboot right now ;)

• This reply was modified 269 days ago by  Erik “kusma” Faye-Lund.

The abstraction that allows it to run in a Chrome browser on multiple platforms does not deduct from the fact that it is still native code. And the fact that Chrome loads and runs this instantaneously without notice scares me even more. Seems like they’re really confident.

That said, a demo running native code *and* hardware shaders is no longer a web-platform demo. It’s a native process hosted (and shielded) by a browser, not much different from a straight executable at all. If JavaScript/WebGL is giving you a raw deal, performance-wise, then perhaps it’s time to consider if you’re using the right technology for the job :)

Well okay, you get free Mac and Unix (or whatever your main OS is) as long as you target x86/x64 hardware.

I just don’t see why browser vendors need to keep beating this dead horse over and over again. They’d better spend even more effort on getting widely supported higher level technology faster and better.

• This reply was modified 268 days ago by  niels.
• This reply was modified 268 days ago by  niels.

Now that’s stretching things out of proportion?

Just saying that there are more suitable tools if JS can’t give you the performance you need. And I also said that I really don’t think a demo is “webbased” anymore as soon as it uses a native process to do the thinking and the graphics card for the rest. Then again competitions will probably be unified pretty soon, as far as that isn’t the case already.

For as far as it wasn’t very clear, I’m just not a fan of everyone and their brother writing native code to run in my browser :) Lets just stick to some standards and make that work instead.

I am a hypocrit though because I don’t enjoy coding JS and the likes and I already downloaded the SDK :)