5 ms·

HTML5 games faster than native?

26 points by AshleysBrain 14y ago

willvarfar 14y ago
> How come the result is suddenly so much better? Unfortunately I don't know enough about the technical details to say for sure And then the author specluates. It is a given that the OpenGL pipeline is more efficient than Direct3D. That's what is actually being measured here. http://www.extremetech.com/gaming/133824-valve-opengl-is-faster-than-directx-even-on-windows http://www.extremetech.com/gaming/133824-valve-opengl-is-fas... In my experience, webGL has some nasty performance gotchas and native, full OpenGL can be much faster still because of instancing, attribute divisors and so on.
- angersock 14y ago
  It's a fresh rewrite of a pipeline originally in DirectX. Unless they went and decided to write optimal DX11 code too, I would be very hesitant to ascribe too much awesome to it.
eswangren 14y ago
This is a useless performance comparison. Among other glaringly obvious issues (such as "How come the result is suddenly so much better? Unfortunately I don't know enough about the technical details to say for sure"... right...) you have this gem: There is another important aspect of the result: our WebGL renderer is designed to be more efficient than our old C++ DirectX 9 engine from Construct Classic. Ok, so you are comparing a highly optimized version to one which you specifically state is inefficient. I don't even know what to say to that...
mtgx 14y ago
How long until WebGL includes the new OpenGL ES 3.0 features?
angersock 14y ago
Without seeing the source code for the application, including the entire DX engine, this is a useless comparison. There are really dumb ways of using all the different C++ libs and features out there, and there are really smart ways of writing WebGL (read: OpenGL ES 2.0 ish) code. The author might be running into other threading issues in their old DX9 engine code, they might be locking things, they might be doing whatever, and the web stuff my be skipping that. This is a rubbish comparison unless we see the whole picture--might as well compare a new bicycle doing a quarter mile to an old pickup with a clapped-out transmission, and then decide cars are now useless.
- AshleysBrain 14y ago
  Hey, author here. Construct Classic is actually open source - the renderer code is here: http://construct.svn.sourceforge.net/viewvc/construct/Common/CDisplay.cpp?revision=172&view=markup http://construct.svn.sourceforge.net/viewvc/construct/Common... I don't think we did anything really dumb - but it was quite a long time ago now! We did still spend a fair amount of time optimising it. I still think its amazing the two could be so close, when personally I think both are reasonably well written. At the time Classic beat a bunch of our old competitors on performance, too.
  - angersock 14y ago
    Ah, hey, no sweat. Didn't mean any offense--I'm just a bit skeptical of the methodology. Yeah, it's cool that the performance is comparable at all. :) If you'd be interested in chatting about engine dev, hit me up through my profile. Always happy to talk shop.
SG- 14y ago
my Chrome in OSX was reporting 240,000 objects on screen at 30FPS. maybe there's just some bug in Chrome? This is on a i5 2500k @ 4.2Ghz with an Nvidia 670.
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.
randallu 14y ago
Actually, Chrome's WebGL implementation is somewhat inefficient since another process actually talks to the driver (separate process from the one executing JS). This shouldn't matter if you can factor your render loop into uploading textures and vertices infrequently and having the majority of frames consist of setting shaders and uniforms and calling drawArrays...
- krsunny 14y ago
  HOW DO YOU KNOW ALL THIS GAHHH!!!!! I WANT TO KNOW THESE THINGS TOOOOOO
  - krsunny 14y ago
    Really guys? Downvotes? You can't deny how scattered good webgl info is. You may have just downvoted the next Mr. Doob. Ill remember that.
    - qu4z-2 14y ago
      It wasn't really a helpful contribution to the discussion, and was likely downvoted on form as much as as on content. Asking for more information about this sort of thing is good and important, but all caps and excessive exclamation marks are, I think, seen as intentionally sloppy. Take a look at the HN Guidelines, specifically the comment sections: http://ycombinator.com/newsguidelines.html http://ycombinator.com/newsguidelines.html EDIT: Also, complaining about downvotes is generally seen as bad form.
deleted 14y ago
[deleted]
vilya 14y ago
The title is a bit sensationalist. The real conclusion, as the author admits towards the end, is that smartly written & optimised javascript can beat lazily written c++ on this particular test.
ndesaulniers 14y ago
JIT'ed code has the added benefit of run time analysis. You can do more aggressive optimizations of code based on previous execution.

26 points by AshleysBrain 14y ago

> How come the result is suddenly so much better? Unfortunately I don't know enough about the technical details to say for sure And then the author specluates. It is a given that the OpenGL pipeline is more efficient than Direct3D. That's what is actually being measured here. http://www.extremetech.com/gaming/133824-valve-opengl-is-faster-than-directx-even-on-windows http://www.extremetech.com/gaming/133824-valve-opengl-is-fas... In my experience, webGL has some nasty performance gotchas and native, full OpenGL can be much faster still because of instancing, attribute divisors and so on.

angersock 14y ago
It's a fresh rewrite of a pipeline originally in DirectX. Unless they went and decided to write optimal DX11 code too, I would be very hesitant to ascribe too much awesome to it.

eswangren 14y ago

This is a useless performance comparison. Among other glaringly obvious issues (such as "How come the result is suddenly so much better? Unfortunately I don't know enough about the technical details to say for sure"... right...) you have this gem: There is another important aspect of the result: our WebGL renderer is designed to be more efficient than our old C++ DirectX 9 engine from Construct Classic. Ok, so you are comparing a highly optimized version to one which you specifically state is inefficient. I don't even know what to say to that...

mtgx 14y ago

How long until WebGL includes the new OpenGL ES 3.0 features?

angersock 14y ago

Without seeing the source code for the application, including the entire DX engine, this is a useless comparison. There are really dumb ways of using all the different C++ libs and features out there, and there are really smart ways of writing WebGL (read: OpenGL ES 2.0 ish) code. The author might be running into other threading issues in their old DX9 engine code, they might be locking things, they might be doing whatever, and the web stuff my be skipping that. This is a rubbish comparison unless we see the whole picture--might as well compare a new bicycle doing a quarter mile to an old pickup with a clapped-out transmission, and then decide cars are now useless.

AshleysBrain 14y ago
Hey, author here. Construct Classic is actually open source - the renderer code is here: http://construct.svn.sourceforge.net/viewvc/construct/Common/CDisplay.cpp?revision=172&view=markup http://construct.svn.sourceforge.net/viewvc/construct/Common... I don't think we did anything really dumb - but it was quite a long time ago now! We did still spend a fair amount of time optimising it. I still think its amazing the two could be so close, when personally I think both are reasonably well written. At the time Classic beat a bunch of our old competitors on performance, too.
- angersock 14y ago
  Ah, hey, no sweat. Didn't mean any offense--I'm just a bit skeptical of the methodology. Yeah, it's cool that the performance is comparable at all. :) If you'd be interested in chatting about engine dev, hit me up through my profile. Always happy to talk shop.

SG- 14y ago

my Chrome in OSX was reporting 240,000 objects on screen at 30FPS. maybe there's just some bug in Chrome? This is on a i5 2500k @ 4.2Ghz with an Nvidia 670.

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.

randallu 14y ago

Actually, Chrome's WebGL implementation is somewhat inefficient since another process actually talks to the driver (separate process from the one executing JS). This shouldn't matter if you can factor your render loop into uploading textures and vertices infrequently and having the majority of frames consist of setting shaders and uniforms and calling drawArrays...

krsunny 14y ago
HOW DO YOU KNOW ALL THIS GAHHH!!!!! I WANT TO KNOW THESE THINGS TOOOOOO
- krsunny 14y ago
  Really guys? Downvotes? You can't deny how scattered good webgl info is. You may have just downvoted the next Mr. Doob. Ill remember that.
  - qu4z-2 14y ago
    It wasn't really a helpful contribution to the discussion, and was likely downvoted on form as much as as on content. Asking for more information about this sort of thing is good and important, but all caps and excessive exclamation marks are, I think, seen as intentionally sloppy. Take a look at the HN Guidelines, specifically the comment sections: http://ycombinator.com/newsguidelines.html http://ycombinator.com/newsguidelines.html EDIT: Also, complaining about downvotes is generally seen as bad form.

deleted 14y ago

[deleted]

vilya 14y ago

The title is a bit sensationalist. The real conclusion, as the author admits towards the end, is that smartly written & optimised javascript can beat lazily written c++ on this particular test.

ndesaulniers 14y ago

JIT'ed code has the added benefit of run time analysis. You can do more aggressive optimizations of code based on previous execution.