HTML5 performance test

Hi all,

In response to lucid's thread, I've made two projects to test HTML5 graphics performance, one for CC and one for C2. Both create as many sprites on the screen as possible before the framerate falls to 30fps. I've adjusted both projects to try and make them as fair as possible, they're attached at the bottom. This only tests the drawing speed - not the event engine efficiency.

The .cap is a Classic r1.2 project. Its engine is optimised C++ code and as you know it uses DirectX 9 to render everything hardware accelerated.

The .capx is a Construct 2 r45 project. Its performance depends almost entirely on the browser. IE9 is by far the best performing browser, so if you're on Vista or 7, try testing with that.

You can run your own tests to see how it fares for you. You will need to leave it running for a while, and give it at least 10 seconds to stabilise - it takes objects away if the FPS drops below 29, and adds more if it's still above 30, so it may take a while to settle down and get the best number. Make sure no other applications are running during the test, for fairness.

Remember: This is testing on-screen objects - many games will have hundreds of objects, but rarely have more than a hundred on-screen at once. When they're offscreen, obviously they take no drawing time at all.

Here are my results. You can check your graphics card by clicking the about icon in C2.

Graphics card: GeForce Go 7600 (old laptop graphics card)

Classic: 748 objects

C2 with IE9: 619 objects

C2 with Chrome 12: 124 objects (if you go to about:flags and turn on the experimental 'GPU accelerated canvas 2D', this goes up to 450 objects! I think this will be enabled by default in a future version of Chrome)

C2 with Firefox 5: They've blacklisted my graphics card driver from hardware acceleration, presumably because it's old. If I force it enabled (about:config - gfx.direct2d.force-enabled), I can get up to 440 objects. Without that it struggles to get over 20 objects but I think that's because my laptop is so old they've decided not to support it.

Conclusion: Support is a bit patchy and still in-the-works on Firefox 5 and Chrome. IE9 performs the best, though, and is 82% as fast as Classic. That's awesome, considering it's running in a browser! FF5 and Chrome, once their support is sorted out, are both about 60% as fast as Classic. That's still fairly good, considering most games in Classic probably don't push the renderer that hard.

Bottom line: HTML5 seems to be pretty fast!

My Test:

Graphics card: GeForce 9600GT

Classic: 3810 objects

C2 with IE9: 3191 objects

C2 with Chrome 12: 539 objects , accel. canvas : 540

C2 with Firefox 5: 2107 objects

Chrome is going very bad. Hope they fix this soon. Not only that but only with one object to render it stutters as hell. It's practically unusable.

The IE9 team made an awesome job .

Graphics card: XFX ATI Radeon HD 5770 1024MB GDDR5

Construct 2

Chrome: 604 objects

Chrome + Experimental GPU flag: 3,030 objects

IE9: 4,014 objects

Firefox 5: 3,214 objects

Safari 5.0.5: ~60 objects, becomes very unstable.

Construct Classic

3,507 objects

On a Geforce 9800gt/AMD athlon 64 x2 4400+:

CC: 3967 sprites

C2: Firefox 5: 990, chrome: 119, IE9: 1055

A lot of that is because of the pixel fill rate of the card, though. It gets interesting if you resize the sprite to 12 by 12 and run it again:

CC: 40,000

C2: Firefox 5: 1099, chrome: 1542, IE9: 1324

Also, I think the speed of the behavior/event system is kind of important to check as well. I made my own speed test with the bullet behavior on a 12 x 12 sprite and I get 60 frames per second with about 500 sprites in chrome and IE9.

http://www.amirai.net/forums/C2speedtest.zip

Construct classic gets to about 12,000 sprites before it dips below 60 frames per second. That's a performance difference of about 20:1!

http://www.amirai.net/forums/CCspeedtest.zip

Also, I'm a little confused - you said HTML 5 is supposedly able to be close to c++ speeds (when compiled to machine code), but you also said that it wasn't fast enough to do pixel perfect collisions.

BTW, weird performance on the test I made in Firefox 5 - If I run the test I made with zero sprites, I get 60 frames per second. Creating one 12 x 12 sprite with bullet behavior drops the frames per second to 45, and it can only manage that fps with 100 sprites on screen. I'm guessing that's a Firefox quirk, but I thought I should mention it.

GeForce 570

Classic: 10319 objects

C2 with IE9: 3322 objects

C2 seems to be smoother with creating new objects, They appear on screen more nicely

thanks ashley for the answers in both threads, still kinda curious about the calculation and command end of things, the plug does slightly graphics intensive stuff, but ridiculous craploads of math

radeon 6970

c2:ff ---------------------------------3648

c2:ie----------------------------------4560

cc:exe(preview, not export)-----17322

— - yep, for security reasons browser makers sometimes blacklist drivers, like Firefox 5 did with my card - you'll get software rendering if your drivers aren't up to date. (Sadly nVidia don't seem to have any recent drivers for my card.)

Tom - first sighting of IE9 being faster than Classic! Impressive!

A lot of that is because of the pixel fill rate of the card, though. It gets interesting if you resize the sprite to 12 by 12 and run it again:

You're right - if you do that the time to render the sprite is very small, and then you end up basically measuring the overhead per draw call. CC is exceptionally good here - it has an extremely low overhead renderer, specially written for that goal. However, it's an unrealistic goal - even with lots of particle effects, it's very rare for games to be drawing more than a few hundred sprites on screen! So CC is optimised for a very rare use case. So I actually don't think it's important that browsers aren't so good there. When do you ever have 10,000+ 12x12 objects on-screen other than in some technical test? The reduced performance is probably the overhead of the javascript, browser security checks and overhead, and so on.

As for your other test, it probably still is only measuring small-object draw performance. A test that checks the raw event running performance - perhaps a 'repeat 10,000 times' event performing some simple action - would be interesting. I might make one!

Also, I'm a little confused - you said HTML 5 is supposedly able to be close to c++ speeds (when compiled to machine code), but you also said that it wasn't fast enough to do pixel perfect collisions.

Google claim their Crankshaft engine is close to C in speed. However, the pixel perfect collision engine in CC is also very unusual in its extreme efficiency - between Davo and I, we came up with a system that generates bitmasks in memory (one bit per pixel) and intersects them using MMX instructions to check 64 pixels in one CPU instruction! It had to deal with rotation, scaling, byte-addressing and bit shifting, machine endian, aligned allocation and memory padding to name a few of the challenges. It's probably one of the most extraordinary bits of code I've helped write. In short, it uses every trick that C++ offers to access the raw CPU capabilities. Javascript offers very few of those capabilities. It's a browser programming language, not a machine programming language.

But who knows - maybe it will be possible in the future? Browsers and processors are getting faster after all... polygon collisions are a safe bet for the time being, though.

still kinda curious about the calculation and command end of things, the plug does slightly graphics intensive stuff, but ridiculous craploads of math

quote]

A test that checks the raw event running performance - perhaps a 'repeat 10,000 times' event performing some simple action - would be interesting. I might make one!.

please do

As for your other test, it probably still is only measuring small-object draw performance. A test that checks the raw event running performance - perhaps a 'repeat 10,000 times' event performing some simple action - would be interesting. I might make one!

Aw, DUH - fixed behavior speed test, with invisible sprites:

http://www.amirai.net/forums/CCbehaviorspeedtest.zip

http://www.amirai.net/forums/C2behaviorspeedtest.zip

CC: 25,000

Firefox 5: 3188 with a small window, can't even manage 60 fps with the window maximized

Chrome: 11,000

IE9: 5471 if window not maximized, 100 if it is. Weird that performance in Firefox and IE gets hit so hard by the window being maximized! It's a 1080p monitor, by the way.

EDIT: Here's an event speed test too:

http://www.amirai.net/forums/CCeventspeedtest.zip

http://www.amirai.net/forums/C2eventspeedtest.zip

CC: 385fps

Firefox 5: 41/21 maximized

Chrome: 41

IE9: 38/22 maximized

Card: RadeonHD 4650

Construct Classic: 995 objects

Construct Classic 2nd run: ~580 objects

Construct 2, Chrome: 255 objects

Construct 2, Firefox4: 566 objects

Construct 2, Chrome 2nd run: 263 objects

Construct 2, Firefox4 2nd run: 567 objects

I don't have IE9 on my stationary pc so I didn't test that.

I did have some stuff in the background though so it might not be 100% accurate. Was msotly curious what the numbers would be. Will probably try it tomorrow with the computer freshly rebooted and see what the difference will be. (I think it's worth doing tests like this with stuff running in the backgroun in addition to test with nothing else running, because the games will probably be running when other stuff are running as well.)