I've been upgrading my PC this week in the Scirra office. Now I'm on Windows 8 with a new nVidia GeForce GTX 660 graphics card. I actually bought it based on some reports from the forum of some unusually high performance results with our WebGL performance test with top-end nVidia cards. So once everything was all set up, I ran the performance test once more.
The result blew my mind. I am not sure if something has gone wrong, or if the test is somehow incorrect. But with this setup and running in Chrome 25, Construct 2's WebGL renderer is faster than our previous native C++ DirectX 9 based engine - the one we developed for Construct Classic.
The WebGL test can reach 141,911 sprites on-screen. The Construct Classic test reaches 109,280. The WebGL result is almost 30% faster than native.
Try it for yourself: here's the WebGL performance test, and the same in native from Construct Classic (warning: EXE). My full setup is: Windows 8 RTM (64 bit), Intel Core i5-2500 @ 3.3GHz (quad core), 8 GB RAM, nVidia GeForce GTX 660 (driver v306.97). However, note I could not reproduce similar results on Windows 7 with a different AMD Radeon card (which I haven't tried on Windows 8 yet). Firefox 19 also came in slower than native, and of course IE doesn't support WebGL at all. So it seems likely many of you reading this will not be able to reproduce the same results; you will likely see WebGL coming in a few times less than the native test. But with the right setup, it seems possible that WebGL can overtake the native.
There's also the test with WebGL disabled, so it always renders with the Canvas 2D renderer. Chrome 25 scores 3821 on this one for me, making the WebGL result a whole 37 times faster in the same browser. Now I'm really glad we wrote a WebGL renderer!
How come the result is suddenly so much better? Unfortunately I don't know enough about the technical details to say for sure. I have a theory: it may be to do with moving WebGL's security checks in to hardware. The WebGL specification mandates that browsers must check all buffers are used correctly, and not accessed beyond the end or before the start. With the long buffers used for rendering large numbers of sprites, it could be a CPU-draining job to keep checking through the buffers to ensure they are used safely. However, some GPU manufacturers may now be able to do these checks on the GPU hardware, which frees the CPU from this security check entirely. Perhaps this is only enabled if your specific OS, driver and hardware setup allows it, otherwise the CPU check is still done. This could explain the vastly improved result on some systems. On the other hand, this is pretty much a guess and it may be something else entirely. I'd love it if any graphics engineers can explain this - email me at firstname.lastname@example.org or post a comment below and I'd be happy to do a followup blog post explaining further!
I really hope this is not some technical fault or bug that I'm misinterpreting, and if so I will be quite embarrassed about spouting such a load of rubbish. On the other hand, if this is a real result, it's a pretty fascinating one. Most of the time you hear people wondering exactly how much slower an app will be once ported to HTML5 from native. How often do you hear that it ended up faster?