Performance: in fairness

Interesting, Did you investigate why some where better than others? Did you use a WebGL inspector? My conclusion on another thread was draw calls. Less draw calls/draws = better performance, maybe this can help me investigate this further.

tunepunk, no, I didn't do an in-depth investigation. However, if pure draw calls were the limiting factor then each engine should have max'd out at the same value when rendering bunnies. Therefore, I think that there's an overhead that each engine carries when ascribing draw calls to the GPU, such that the final yes-render figure is a mix of a GPU and a CPU limitation. The test also didn't measure jank (because I couldn't be bothered to create an fps-waterfall graph for each one) - that would also be of value because it would represent a measure of the quality of the player's experience.

Interesting results indeed. That gap between Unity and C2/Godot is huge. I wonder what causes that.

I think it's worth noting that 6000/9000 bunnies with an Intel HD4000 GPU in C2 is quite acceptable imho.

Is the Godot engine native? If so, nice evidence that HTML5 can reach native performance!

BTW I generally use 30 FPS as the cutoff for performance tests - 55 is a bit close to the v-sync limit, where scheduling issues could come in to play.

Not sure if this is possible but, Is there a way to maybe cap the framerate in C2/C3 (I'm using C3 currently)

It would maybe be a good feature to be able to choose to cap frame rate at 30fps or 60fps rather than having the browser trying it utmost to render 60fps if 30fps wil ldo for a particular game.

Ashley - Godot compiles c++ from the user's GDscript (python) at export. It is run in a wrapper that's the same .exe as the editor runs from in windows (not sure about android export). It does show html5 can perform ok, but I think Unity is the only native engine in this group - which is why it's so much faster.

Havok - Unity's graceful degradation from 60 to 30 fps was a clincher. No jank....

Looks like Unity's rendering performance is only about 25% better than the HTML5 version, so not that big a difference when it comes to on-screen sprite throughput.

If GDScript is python-like, then compiling it to C++ won't make it fast - it'd need a proper JIT to compile it well. JavaScript happens to have excellent JIT support, so that would explain why it's faster. So there seems to be a good argument here that JavaScript is faster than GDscript.

There's a request to support 30 FPS rendering in Chrome here, star it to show your support: https://bugs.chromium.org/p/chromium/issues/detail?id=485600

Could someone explain to me why NW.js performs a bit worse compared to Chrome?

Aren't both browsers essentially running on the same backend (Chromium)?

There's no good reason for them to be different - they are based on the same browser engine. I'd suspect it's just a margin of error in the test, or a quirk of only measuring to 55 FPS where v-sync scheduling comes in to play.

Colludium could we perhaps change the testing criteria to 30fps?

(Since there is no way to manually throttle down to 30fps, I would recommend just adding bunnies until 30FPS have been reached.)

Also just out of curiosity, since Unity also offers WebGL exporting.

Would you mind providing performance stats for that as well?

Might be interesting to see how Unity's WebGL export performs, compared to C2's.

Sure TheRealDannyyy - I'll take a look at Unity webgl as well. It'll be some time in the next couple of days, though. Work is hectic... I also wondered about why Chrome beat NWjs - I put it down to the NWjs engine dev being in lag behind Chrome.

I think 30 fps stress testing won't give any good info - most players will have gone home by then, and it might just test aspects of the engines that are irrelevant for normal gaming.

Sure TheRealDannyyy - I'll take a look at Unity webgl as well. It'll be some time in the next couple of days, though. Work is hectic... I also wondered about why Chrome beat NWjs - I put it down to the NWjs engine dev being in lag behind Chrome.

I think 30 fps stress testing won't give any good info - most players will have gone home by then, and it might just test aspects of the engines that are irrelevant for normal gaming.

Yeah the 30fps test would just be for testing purposes in this specific case, obviously nobody wants a game running on lower framerates than 60fps.

No probs for the delay, take your time and do it whenever you can.

Thanks for doing all this by the way, it's quite interesting.

Thanks for doing all this by the way, it's quite interesting.

+1 Indeed. Thank you for taking the time for creating and showing us these measurements.

—, TheRealDannyyy, happy to help. I did have the old apks on my phone (all but Godot's).

30fps no render

Godot: 1200

C2: 1800

Unity: 5500

30fps with render:

C2: 1600

Unity: 2000

The Unity version was smoothest because of the framerate lock.