I can speak to WebGL as we've actually built some stuff on top of it. Yes performance is good, sometimes. But if your user is on hardware like Intel X3100 graphics cards, then the WebGL context will run in software mode, performance will be dismal, and you as a developer don't have any real checks to see that.
Secondly, hardware support for WebGL is very dismal right now. For example, newly shipping MacBook Air's don't support WebGL.
Third, we found so many inconsistencies across different hardware and different browsers that it made it not worth it to work on a WebGL project for the time being, especially for a small team. We wrote a number of runtime checks, but we still could not account for all the bugs, or find ways around every one of them.
If you're writing a new 2D game in HTML5 from scratch, you'll have a much larger market share by going after a slightly simpler (artistically) game using canvas, rather than trying to go for more horsepower with WebGL. However, WebGL can be useful for porting, if you'd like to see an OpenGL game you've already made come to the browser.
How new? My MBA is only 2 or 3 months old and WebGL runs fine (and fast) under Chrome 17. Indeed, under the test on the parent link, I get about 500 objects on Canvas, 6000+ on WebGL.
WebGL is disabled by default in Safari on Air (maybe other Macs too) but if you go to Preferences/Advanced and check "Show Develop menu" then you will be able to enable WebGL support through Develop menu. On my Mid-2011 Air it appears pretty fast.
"Finally it's a shame no mobiles support WebGL yet. iOS actually supports WebGL, but they've disabled it! I'm not sure why they've done this, because enabling WebGL is crucial to high performance HTML5 games on mobiles."
The cynic says: App store! App store! Money money money!
Could be good reasons. Perhaps Apple's webGL implementation actually could be used for exploits, and until it's secure they won't allow it for general use. Notice the one place Apple does allow WebGL is iAds, which are reviewed & controlled by Apple.
And the cynic is an knee-jerk idiot. The App Store is not Apple's money maker by a large margin, selling iPhones is.
Also Apple HAS added WebGL support to iOS, only hasn't enabled it yet. Tons of reasons exist: battery issues, the implementation not being ironed out yet, and the security risk of WebGL.
Apple cares about the experience of using an iPhone, and if WebGL games on mobile safari suck the batter dry, stall or even crash, they aint gonna enable it just for to add one for mark on the iPhone spec sheet.
if the renderer can leave the majority of the frame time free for game logic to run, it's done its job. Consider it this way: Chrome 15 leaves 86% of the frame time free and Classic leaves 97.6% of the frame time free
Well, if you're going to evaluate it that way then surely you also have to account for the game logic running much slower in JavaScript than in C++.
The bottom line is: If you care about graphics rendering, C++ wins by a large margin. And if you care about game logic, C++ wins by an even bigger margin.
You have to put this test in context. It's basically testing how fast you can take floating-point values out of JS objects, put them in vertex buffers, and shuttle them through the JS <-> C foreign-function interface into the GL library. This is pretty much a worst-case scenario for JS, and Opera gets within about 4x of C++.
For more complex rendering, JS will be faster, relatively, because the GPU will have to do more work for each batch of vertices you send over.
For game logic, JS will be faster, relatively, because going through the foreign function interface is actually somewhat slow. You have to pin GC'ed objects onto the stack, etc. Moreover, calling into code the JIT can't see can disable certain optimizations.
If you look at certain FP micro benchmarks, like nbody and spectrum-norm in the Shootout, V8 is within 4x of gcc -O3 on nbody, within 3x on spectral-norm when using gcc's vector extensions, and dead-even with gcc on spectral-norm when not using gcc's vector extensions.
The places where V8 still falls down are property access (the prototype OO system forces some overhead) and lack of vectorization. The former can be addressed by using an SoA layout rather than an AoS layout, and if your code is amenable to vectorization you should break out the assembler anyway.
A good part of game logic is done in a "scripting" language these days. For example Lua is used in WoW & Starcraft 2 and the newer Civilization games use Python. Generally they do use the core C++ engine to all the math heavy tasks like collision detection.
As a side note, if GPUs and CPUs are both that awesome these days, why do side-scrollers still not look perfect? I've been playing Braid on OS X and while it's a pretty game, scrolling is just noticeably blurry (and this is on a pimped-out MacBook Pro Core i5, NVIDIA GeForce GT 330M).
I've just always held out hope that once the hardware is fast enough, side-scrollers would look just as crisp scrolling as they do standing still.
Performance is more to do with the framerate than visual quality - if you see blurry artwork it may be driver bugs, bad coding, sprites stretched with the wrong quality, or other things like that.
I wonder whether your huge[1] runtime had any effect on the benchmarks. Wouldn't using pure Javascript have been a better idea?
I also notice your "C++" version used Direct3D. Shouldn't you have used OpenGL with the exact same calls as the JS to get a fair comparison with the WebGL versions?
Under the hood most (Chrome and Firefox) WebGL implementations use D3D9 on Windows through Angle (http://code.google.com/p/angleproject/) anyway. There is of course additional overhead in WebGL implementations, Javascript and using Angle as a translation layer, but this is a fair comparison, eventually those sprites are getting rendered by the same drivers and same D3D runtime.
It's a 61kb script minified, and jQuery 1.7 is currently 91kb. Yes jQuery is likely to be cached but IMO it's not huge, one of the game's images could easily be 61kb too. On top of that we've seen some competing tools generating like half a megabyte of JS :P
Edit: also our intent was to compare real game engines, which necessarily add some performance overhead, rather than a thin experiment.
Hmmm ... the author says that percentage of frame time left for game logic is the important factor, but if raw c++ is around 6 times faster, doesn't that mean you can do 6x more sophisticated game logic in a given amount of free time as well?
That said, the webgl performance in chrome is indeed (relatively) impressive. Am also a macbook air user and have no trouble getting good performance on it.
One point to note is that the webgl engine in chrome runs all graphics in a single process, atleast partly for reasons of security (shader code gets checked by the browser before being set to the gpu, for example). That is sort of like a driver on top of a driver and so there will always be like a 2x performance gap between webgl and c++ i think.
For a given number of triangles/quads, you have a certain amount of time left in the frame period for the game logic. Say 5 ms out of a 17 ms frame (@60 FPS). A faster language like C++ is going to take less time for feeding vertex data to the GPU. So instead of taking 12 ms to push the vertices it may take 2 ms, giving you 15 ms for game logic instead of 5, a 3x increase in time.
The game logic will likely be faster by a similar factor, so you could quite possibly get an 18x increase in game logic capacity.
Why was the development version of Opera used, but not of the other browsers? Both stable and development Opera is shown there, but just stable versions of the other ones.
The development Opera does great, but the development versions of the other browsers are likely also much faster than their stable versions.
It's only included in the last chart, with this explanation: "The Opera 12 alpha comes with hardware acceleration but since it's alpha I don't want to include its results yet - sometimes making software more reliable also means making it a little slower, and considering I used the stable branches for all the other browsers I also thought it would be unfair to include Opera 12 alpha (until the end where I throw it in for fun)."
It seems that Canvas 2D isn't accelerated by Firefox 7 on Linux at all. I'm only able to get about 600 objects, versus ~4200 with WebGL. Chrome's Canvas settles at ~4200-4300 on the same system (WebGL does ~6100).
Very interesting analysis. Still, when comparing to C++, we have to consider that with a game that actually does something (game logic, interaction etc.) C++ advantage would be much bigger.
Actually C++ advantage would be smaller, since the test isn't at all GPU bound. It's basically testing how fast you can copy data through the JS <-> C++ FFI into the GL library.
A test that stayed within JS would optimize better and perform better relative to C++.
I have a feeling they'll announce the Chrome port to Android at Google I/O next year (which is also a Chrome event), and it might get WebGL support along with it. I know some people were asking the devs about WebGL on Android at last I/O, so they might've taken that into consideration for the next I/O.
It would be a good time to do it, too, because otherwise Mozilla and Opera will do it anyway next year.
[+] [-] alexhaefner|14 years ago|reply
Secondly, hardware support for WebGL is very dismal right now. For example, newly shipping MacBook Air's don't support WebGL.
Third, we found so many inconsistencies across different hardware and different browsers that it made it not worth it to work on a WebGL project for the time being, especially for a small team. We wrote a number of runtime checks, but we still could not account for all the bugs, or find ways around every one of them.
If you're writing a new 2D game in HTML5 from scratch, you'll have a much larger market share by going after a slightly simpler (artistically) game using canvas, rather than trying to go for more horsepower with WebGL. However, WebGL can be useful for porting, if you'd like to see an OpenGL game you've already made come to the browser.
[+] [-] petercooper|14 years ago|reply
How new? My MBA is only 2 or 3 months old and WebGL runs fine (and fast) under Chrome 17. Indeed, under the test on the parent link, I get about 500 objects on Canvas, 6000+ on WebGL.
[+] [-] pandaman|14 years ago|reply
[+] [-] AshleysBrain|14 years ago|reply
[+] [-] fennecfoxen|14 years ago|reply
The cynic says: App store! App store! Money money money!
[+] [-] robterrell|14 years ago|reply
[+] [-] dextorious|14 years ago|reply
Also Apple HAS added WebGL support to iOS, only hasn't enabled it yet. Tons of reasons exist: battery issues, the implementation not being ironed out yet, and the security risk of WebGL.
Apple cares about the experience of using an iPhone, and if WebGL games on mobile safari suck the batter dry, stall or even crash, they aint gonna enable it just for to add one for mark on the iPhone spec sheet.
[+] [-] extension|14 years ago|reply
Well, if you're going to evaluate it that way then surely you also have to account for the game logic running much slower in JavaScript than in C++.
The bottom line is: If you care about graphics rendering, C++ wins by a large margin. And if you care about game logic, C++ wins by an even bigger margin.
[+] [-] rayiner|14 years ago|reply
For more complex rendering, JS will be faster, relatively, because the GPU will have to do more work for each batch of vertices you send over.
For game logic, JS will be faster, relatively, because going through the foreign function interface is actually somewhat slow. You have to pin GC'ed objects onto the stack, etc. Moreover, calling into code the JIT can't see can disable certain optimizations.
If you look at certain FP micro benchmarks, like nbody and spectrum-norm in the Shootout, V8 is within 4x of gcc -O3 on nbody, within 3x on spectral-norm when using gcc's vector extensions, and dead-even with gcc on spectral-norm when not using gcc's vector extensions.
The places where V8 still falls down are property access (the prototype OO system forces some overhead) and lack of vectorization. The former can be addressed by using an SoA layout rather than an AoS layout, and if your code is amenable to vectorization you should break out the assembler anyway.
[+] [-] Game_Ender|14 years ago|reply
[+] [-] haberman|14 years ago|reply
I've just always held out hope that once the hardware is fast enough, side-scrollers would look just as crisp scrolling as they do standing still.
[+] [-] MrScruff|14 years ago|reply
[+] [-] AshleysBrain|14 years ago|reply
[+] [-] udp|14 years ago|reply
I also notice your "C++" version used Direct3D. Shouldn't you have used OpenGL with the exact same calls as the JS to get a fair comparison with the WebGL versions?
[1] http://www.scirra.com/labs/perftest-2d/c2runtime.js
[+] [-] Impossible|14 years ago|reply
[+] [-] AshleysBrain|14 years ago|reply
Edit: also our intent was to compare real game engines, which necessarily add some performance overhead, rather than a thin experiment.
[+] [-] aufreak3|14 years ago|reply
That said, the webgl performance in chrome is indeed (relatively) impressive. Am also a macbook air user and have no trouble getting good performance on it.
One point to note is that the webgl engine in chrome runs all graphics in a single process, atleast partly for reasons of security (shader code gets checked by the browser before being set to the gpu, for example). That is sort of like a driver on top of a driver and so there will always be like a 2x performance gap between webgl and c++ i think.
Still ... the future looks bright.
[+] [-] marshray|14 years ago|reply
The game logic will likely be faster by a similar factor, so you could quite possibly get an 18x increase in game logic capacity.
[+] [-] petegrif|14 years ago|reply
[+] [-] azakai|14 years ago|reply
The development Opera does great, but the development versions of the other browsers are likely also much faster than their stable versions.
[+] [-] evmar|14 years ago|reply
[+] [-] nitrogen|14 years ago|reply
[+] [-] danmaz74|14 years ago|reply
[+] [-] rayiner|14 years ago|reply
A test that stayed within JS would optimize better and perform better relative to C++.
[+] [-] nextparadigms|14 years ago|reply
It would be a good time to do it, too, because otherwise Mozilla and Opera will do it anyway next year.
[+] [-] kevingadd|14 years ago|reply
[+] [-] Too|14 years ago|reply
[+] [-] ccanassa|14 years ago|reply
[+] [-] rorrr|14 years ago|reply
[+] [-] AshleysBrain|14 years ago|reply