A question we get asked a lot is “How does PlayCanvas compare to Unity’s WebGL export?”. So let’s examine this in a blog post.
But first, let me quickly introduce Unity and PlayCanvas to the uninitiated. Unity is a game engine provided as a native, desktop application for Windows, Mac and Linux. PlayCanvas is an HTML5/WebGL game engine that is provided as a web application that runs in any browser on any operating system.
For the purpose of this article, we’re keeping things simple. We’ve created the ‘Hello World’ of apps in both Unity 5.3.2 and PlayCanvas: a spinning, textured cube:
The application above is the PlayCanvas app. I’m not embedding the Unity app since it can crash the page (if you’re feeling brave, click here to run it in a new tab).
We decided to look at 3 key metrics: download size, load time and frame rate.
Download Size
To check the download size of each app, we disabled the cache in Chrome Dev Tools and recorded the total transfer:
| Unity | PlayCanvas |
|---|---|
| 4.72MB | 0.22MB |
The Unity app is over 21 times larger than the PlayCanvas app. How is this possible? The PlayCanvas engine is a miniscule 147KB when GZIPped meaning the code and assets for the app account for the remaining 73KB. The engine is so small because it is hand-crafted in JavaScript, relying on as much functionality as possible from the browser itself.
Unity, on the other hand, relies on Emscripten to export to WebGL. This tool auto-converts C# code to C++, which in turn is compiled to LLVM before finally being turned into JavaScript. A side effect of this process is the generation of huge amounts of code, which bloats the exported application, overwhelms modern JavaScript engines and often causes the browser to run out of memory.
Load Time
We ran both apps on 12 different devices, from low end to high end. These were the recorded load times on a 50Mb/s connection to the net:
| Device | Browser | Unity (s) | PlayCanvas (s) |
|---|---|---|---|
| iPhone 4S | Safari | Crash | 2 |
| iPhone 5S | Safari | 18 | 1 |
| iPhone 6 | Safari | 17 | 1 |
| iPad Mini 2 | Safari | 21 | 1 |
| Samsung Galaxy Tab S2 | Chrome 51 | 19 | 1 |
| Samsung Galaxy Note 10.1 2014 | Chrome 51 | 28 | 1 |
| Samsung Galaxy S6 Edge | Chrome 51 | 28 | 1 |
| Samsung Galaxy Note 4 | Chrome 51 | 28 | 1 |
| LG Nexus 4 | Chrome 51 | 44 | 2 |
| Leapfrog Epic | Chrome 51 | 43 | 1 |
| Blackberry Z10 | Default Browser | Crash | 1 |
| PC (Core i7 + GeForce GTX 880M) | Chrome 51 | 13 | 1 |
Key things to notice:
- The PlayCanvas app’s load times are up to 43 times faster than the Unity app.
- The Unity app fails to even load on lower end devices. The sheer amount of JavaScript causes the browser on those devices to run out of memory loading the page.
- Load times for Unity are up to twice as slow in Chrome as Safari. This could be down to Chrome spending more time preparing the app’s huge JavaScript codebase for execution.
Frame Rate
Here are the frame rates recorded for the same set of devices:
| Device | Browser | Unity (fps) | PlayCanvas (fps) |
|---|---|---|---|
| iPhone 4S | Safari | Crash | 58 |
| iPhone 5S | Safari | 21 | 60 |
| iPhone 6 | Safari | 28 | 60 |
| iPad Mini 2 | Safari | 16 | 60 |
| Samsung Galaxy Tab S2 | Chrome 51 | 17-55 | 60 |
| Samsung Galaxy Note 10.1 2014 | Chrome 51 | 15-50 | 60 |
| Samsung Galaxy S6 Edge | Chrome 51 | 15-50 | 60 |
| Samsung Galaxy Note 4 | Chrome 51 | 15-57 | 60 |
| LG Nexus 4 | Chrome 51 | 15-50 | 60 |
| Leapfrog Epic | Chrome 51 | 16-55 | 60 |
| Blackberry Z10 | Default Browser | Crash | 60 |
| PC (Core i7 + GeForce GTX 880M) | Chrome 51 | 57-60 | 60 |
Key things to notice:
- PlayCanvas frame rates are up to 4 times greater than Unity. In particular, Unity seems to perform poorly in Safari on iOS.
- Unity exhibits very unstable performance in Chrome for Android. Initially, the app’s frame rate is in the mid to high teens for approximately 20 seconds before it starts to rise to a number in the 50s. At that point it, it regularly drops frames and never reaches a solid 60FPS.
- PlayCanvas easily locks to 60FPS across all devices except iPhone 4S where an occasional frame is dropped. Ideally, a much heavier stress test would be required to start taxing PlayCanvas.
Conclusion
To summarise:
- Unity WebGL apps are up to 21 times larger.
- PlayCanvas apps load up to 43 times faster.
- PlayCanvas app frame rates are up to 4 times higher.
Even for the most basic of 3D apps, Unity struggles to achieve anything close to acceptable download size, load time and frame rate. It’s important not to somehow blame browser vendors or HTML5/WebGL for these results. As PlayCanvas proves, you can achieve incredible performance using these web technologies today as long as a sensible approach is taken when architecting an engine.
To learn how PlayCanvas built an engine so optimized for the browser, head over to GitHub to explore the open sourced runtime. And if you want to start building with PlayCanvas today, sign up on playcanvas.com.
Update
If you want to look at the original projects that built the two apps used in the article, here is the Unity project, and here is the PlayCanvas project. After publishing this article, we noticed that the Unity project disables hardware anti-aliasing and uses bilinear filtering on the textures, whereas PlayCanvas enables AA and trilinear on the textures. So PlayCanvas is actually doing more work here.
Hi Will, it’s Will, we’d love to validate this our end to check on our own optimisations – care to update the post with a project folder from your Unity tests?
Hi Will,
interesting comparison. I just want to mention that, to be fair, mobile devices are officially supported by Unity WebGL (as mentioned here: https://docs.unity3d.com/Manual/webgl-gettingstarted.html), and that both loading times and performance (framerate) can vary a lot depending on the browser: http://blogs.unity3d.com/es/2015/12/15/updated-webgl-benchmark-results/ (we don’t blame them but these are the facts)
Cheers,
-Marco
I meant “mobile devices are not officially supported by Unity WebGL” 😉
That’s… not exactly strengthening Unity’s case?
it’s about expectations. Unity WebGL on mobile is not supported (yet).
Having said that, things are evolving in the right direction with technologies like WebAssembly which will allow Unity to generate smaller, faster and more memory efficient builds.
Me for example, I am holding of using WebGL in unity as its very slow and very unreliable compared to other engines or frameworks.
With WebAssembly, do you think that you will get just as good results as playCanvas is now? in speed and just not crashing?
It is possible to create small 3D demos that are cross-compiled from C++ if one pays attention to code bloat and let the compiler remove unused code (which Unity apparently doesn’t, or doesn’t very efficiently). With the emscripten runtime, the minimum size seems to be around 100kByte for WebGL demos, for instance this demo: http://floooh.github.io/oryol/asmjs/Shapes.html is a 139KByte download, which is even smaller than the playcanvas rotating cube demo. The browser doesn’t have a lot to offer in terms of built-in features that would save JS size, since most of what a browser does is related to the DOM, which isn’t used by WebGL code.
Hi Will,
I don’t know what is up with your PC benchmark but on my system:
FX8350, r9 380 4g, Win7, Firefox 48.0
the FPS benchmark is almost the exact opposite of your “chrome51 on PC” benchmark, meaning that the PlayCanvas app fluctuates all the time between 60 and 50 fps (sometimes even to a mind-boggling 17 fps for a second or two). All the while the Unity WebGL app runs perfectly fine at a stable 60fps with no drops in FPS even when I change to the respective tab whereas the PlayCanvas app on changing focus to its tab has a drop to ~15fps for 1-3 seconds.
Also why are you only testing Chrome on the PC? There could very well be differences in the observable metrics based on the browser used even though there shouldn’t be from what I read in this article.
I guess the main advantage of Unity would be the single codebase to support. Probably they aren’t worried about it working that well on mobile devices because they can just export natively to those instead. It’s the price you pay for the single codebase for your game. If you are only targetting the web or electron then PlayCanvas is a much better choice. If you have the time & money to port your game from Unity to PlayCanvas for web support then that’d be the best choice as well. It’s attractive to some of course to just be able to publish to a different target from the same source. It’ll get better over time, but it will probably never be the truly better choice than porting to the “native” javascript engine.
Hey, I tested this on the Amazon’s Fire tablet (5th generation model) in the Silk browser. The playcanvas demo runs at 58 – 60 fps. The Unity demo crashes.
I just took a look at the Unity project you posted. Unity can do somewhat better then you claim, IMO. I removed the unused components (Physics Colliders and Audio components, and the build size dropped down to 3.3MB). http://files.unity3d.com/jonas/spin2-53/
I also cannot reproduce your results for load times. The link I posted takes around 4s to load on both Firefox 46 and Chrome 51 on my MacBook Pro. As for AA and trilinear filtering, neither have been enabled in your project, but doing so will not affect performance for such a simple scene.
That said, obviously, those numbers are still not matching PlayCanvas’ numbers for this spinning cube demo – and they never will, due to different nature of the engines. But then, is a spinning cube really a valid comparison? After all, anyone with some WebGL knowledge can easily write a spinning cube (or copy-paste one of many WebGL tutorials for one) in 2-3kb (“100x smaller then PlayCanvas!”). But such a comparison completely ignores the engine’s feature sets. Unity’s strengths are it’s feature set, it’s toolchain and cross platform compatibility (with good options to deploy mobile content as native apps). If you value neither of those and your target is lightweight web content only, then, yes, PlayCanvas may be a better option for you today. We do hope that future browser technologies will make Unity content on the web more accessible then it is now, and possibly change that.
The point is, if Unity struggles to handle a spinning cube, anything more complex is not likely to yield better results. That said, this is just an initial look into the topic and more complex scenarios will be examined in due course.
You’re right that feature sets are not examined here. Unity and PlayCanvas are different – perhaps a good analogy is Unity is MS Office to PlayCanvas’ Google Docs. PlayCanvas has collaboration features far beyond those of Unity, a toolset that runs on mobile as well as desktop, realtime chat, and lots more features besides. And likewise, Unity has features PlayCanvas doesn’t have. But let’s not get bogged down in that. This article intends to make a simple point: taking a web-first approach to engine design makes a real difference.