3 ms·

I don't have a windows machine so I can't run the exe, and so can't be sure what makes the difference here. But there are various things that could explain this

by azakai 14y ago

I don't have a windows machine so I can't run the exe, and so can't be sure what makes the difference here. But there are various things that could explain this. First, the code is not identical in the two cases - the JS version is not identical the native one, it does things differently. So this isn't apples-to-apples. (If the JS was compiled from the original, this would be better, but the code does not appear to be compiled, at least not compiled C/C++.) As one example, WebGL does not allow slow things like client-side state. Rewriting to avoid that will make your code faster than the original. Otherwise, the measurement method can make a difference. The native build might block on flushing the commands, but the WebGL one might do that asynchronously, making it looks like it finished first. So the result is interesting and warrants investigation, no immediate explanation for it that I can see. Could be nothing, could be something.

corysama 14y ago
All good points, azakai. Ashley: Given that you are running on Windows, unless you have manually enabled the desktop OpenGL option in Chrome, your WebGL calls are running through the ANGLE layer. That means they are getting translated to native D3D under the hood. http://blog.chromium.org/2010/03/introducing-angle-project.html http://blog.chromium.org/2010/03/introducing-angle-project.h... A couple more possible explanations: 1) Your performance may be dominated by the overhead of lots of API calls. For example, drawing 4-vertex sprites individually would do that. ANGLE forwards those calls to a separate process for security reasons, but as a side effect you can end up with a whole core devoted to nothing but API overhead. This could actually run a lot faster than API + everything else on a single core. 2) The Transgaming guys working on ANGLE have a lot of experience auto-translating other people's crappy 3D code between OGL<->D3D. (http://transgaming.com/news/transgaming-developing-angle-project http://transgaming.com/news/transgaming-developing-angle-pro...) It's possible that their translation of your OpenGL is a better use of D3D than your own D3D.

by azakai 14y ago

corysama 14y ago

All good points, azakai. Ashley: Given that you are running on Windows, unless you have manually enabled the desktop OpenGL option in Chrome, your WebGL calls are running through the ANGLE layer. That means they are getting translated to native D3D under the hood. http://blog.chromium.org/2010/03/introducing-angle-project.html http://blog.chromium.org/2010/03/introducing-angle-project.h... A couple more possible explanations: 1) Your performance may be dominated by the overhead of lots of API calls. For example, drawing 4-vertex sprites individually would do that. ANGLE forwards those calls to a separate process for security reasons, but as a side effect you can end up with a whole core devoted to nothing but API overhead. This could actually run a lot faster than API + everything else on a single core. 2) The Transgaming guys working on ANGLE have a lot of experience auto-translating other people's crappy 3D code between OGL<->D3D. (http://transgaming.com/news/transgaming-developing-angle-project http://transgaming.com/news/transgaming-developing-angle-pro...) It's possible that their translation of your OpenGL is a better use of D3D than your own D3D.