Scirra cog

About Us

We're a London based startup that develops Construct 2, software that lets you make your own computer games!

Archives

Browse all our blog posts

Latest Blog Entries

We love brains!

Join us! Joiiinnn ussss! Mooooree brains!

HTML5 games faster than native?

by Ashley | 6th, November 2012

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.

WebGL vs. native performance results

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 [email protected] or post a comment below and I'd be happy to do a followup blog post explaining further!

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. When working in C++, it's easy to be lazier - C++ is super fast, so any code you write will be fast, right? When porting our engine to Javascript, we knew it was a few times slower than C++ in most benchmarks. This made us pay much closer attention to performance, as well as taking a smarter overall strategy. Classic's native engine computes the positions of vertices (the object corners) when rendering every single sprite. With Construct 2 we realised these positions are already calculated and cached for use in the collisions engine. This prevents Construct 2 from having to do any vertex calculations at all - they are simply copied out from what the collision engine calculated. So the Javascript engine has less work to do. We thought this might help slightly close the gap between Javascript and C++; perhaps it has a lot bigger effect than we thought!

So, as always, performance is complicated. Javascript is not faster than C++ - this is not what we have proved. Our Javascript engine does less, which helps explain how with just the right circumstances it can edge ahead of a less efficiently written C++ engine. If the C++ engine was written to do the same work as the Javascript one, it would likely be significantly faster again. However since we no longer officially maintain Classic this is unlikely. There's still an interesting lesson here: using a "fast" language like C++ does not guarantee better performance than a "slow" language like Javascript. A smart approach to the problem can make up the difference. This also suggests there may be other native engines out there which could be beaten by a more cleverly written Javascript/WebGL renderer, because the native programmers were lazier! This also bodes well for the future of HTML5 games on mobile, which may be able to actually reach the same benchmark results as native engines (or more!).

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?

Now follow us and share this

Tags:

Comments

-2
Jarzka 3,222 rep

Windows 7 > Windows 8 (mandatory comment).

Tuesday, November 06, 2012 at 7:05:37 PM
3
themitchnz 2,754 rep

Great post, interesting read, I wonder how far this will go?

Tuesday, November 06, 2012 at 7:06:58 PM
-2
Tuxu 2,678 rep

Amazing!
Windows 7 > Windows 8 ( 1)

Tuesday, November 06, 2012 at 7:11:08 PM
2
Konidias 2,260 rep

As great as HTML5 might seem, it's still struggling on older hardware/any iOS devices. I'm going through some issues trying to get even a steady 50fps with my HTML5 game on an ipad. Natively this game would run 60fps no sweat... But iOS doesn't support webGL, so HTML5 games are really not currently an option for iOS if they require any sort of scaling/effects whatsoever.

Tuesday, November 06, 2012 at 7:11:55 PM
2
VampyricalCurse 8,331 rep

This is good indeed. But sadly HTML5 isn't kind on older HW. This, I hope will be dealt with, then HTML5 will be the perfect platform it was envisioned to be.

Tuesday, November 06, 2012 at 7:16:44 PM
2
PixelAmp 4,487 rep

<P>Thanks for the post Ashley. I love seeing these statistics that show the benefits of the platform and getting additional insights into the engine!</P>

Tuesday, November 06, 2012 at 7:18:19 PM
1
noirfluo 6,936 rep

Very interesting ! ! ! (and near... incredible! ;)

Tuesday, November 06, 2012 at 7:18:57 PM
1
Koodari 3,762 rep

Good job! Interesting post also!

Tuesday, November 06, 2012 at 7:19:58 PM
1
boybokeh 4,437 rep

Very interesting indeed!

Tuesday, November 06, 2012 at 7:20:02 PM
7
teerex 3,587 rep

Apple and Microsoft need to update their browsers.
Actually iOS use hardware acceleration... for banners (iAD).
And IE is traditionally one of the slowest running javascript.

Tuesday, November 06, 2012 at 7:32:16 PM
3
Velojet 20.7k rep

Great analysis, Ashley, and clearly and convincingly presented: "Construct 2's WebGL renderer is faster than our previous native C DirectX 9 based engine" - amazing!
But what a racing upgrade treadmill we're on, to enable us to take advantage of these advances!

Tuesday, November 06, 2012 at 7:38:53 PM
2
jwjb 4,884 rep

A very informative post as usual Ashley, thanks so much for the analysis and analytics.

Tuesday, November 06, 2012 at 7:47:50 PM
2
MikeHart 4,157 rep

Funny, on my iMac 2009, with OSX 10.8.2, in Chrome 23 I get around 3700 with WebGL, but with FireFox 16 I get around 15000. Go figure.

Tuesday, November 06, 2012 at 7:51:42 PM
3
sqiddster 32.6k rep

Awesome! Over 100,000 sprites... wow.

Now we just need to wait a few years for everyone's hardware to catch up ;)

Tuesday, November 06, 2012 at 7:59:02 PM
5
dEspadas 4,957 rep

97151 - WebGL
128458 - Native
i3 - 3220 / GeForce GTX 550ti with small factory overclock / Win 7 64 / nvidia driver 306.97 / 8Gb RAM

Edited: Forgot to say that it was Chrome 22.

Tuesday, November 06, 2012 at 8:04:40 PM

Leave a comment

Everyone is welcome to leave their thoughts! Register a new account or login.