|
|
|
|
|
|
by CyruzDraxs
5299 days ago
|
|
|
Yes, but NaCl provides direct access to GPU interface libraries. You can code for OpenGL directly, rather than running your graphics code through several layers of abstraction, slowing it down exponentially along the way. There is, to some extent; hardware acceleration for canvas. But I don't expect that to be at all comparable to native OpenGL for awhile yet. JS has certainly had some significant advances in speed over the last few years, but there's only so much optimization you can do. It's still running in a VM, so there will always be that overhead. Another important thing to consider is that the native API will always have to exist before a Javascript abstraction can. Many triple-a titles will use brand new GPU features to sell the newest line of graphics cards. That won't work if they are making a browser game and the required interface to do those things doesn't exist yet. Javascript will always be chasing the tail of native. |
|
|
If shaders are the bottleneck, and not graphics calls, then NaCl and JS will be the same.
If graphics calls are the bottleneck, then sure, NaCl will be faster - but likely you need to do more batching in your GL code.
> JS has certainly had some significant advances in speed over the last few years, but there's only so much optimization you can do. It's still running in a VM, so there will always be that overhead.
NaCl is essentially also running in a VM: It's sandboxed, so it has performance limitations. There are types of code that run slowly in NaCl, just like in the JVM. However, VM code can be fairly fast in general, the JVM and NaCl are speedy on a lot of code.
The point though is that JS can be fast too - once it has as many years of effort put into it as the JVM and native compilers has, it will be. It's just still very new. "Being in a VM" is not the issue.