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.
To check the download size of each app, we disabled the cache in Chrome Dev Tools and recorded the total transfer:
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)|
|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.
Here are the frame rates recorded for the same set of devices:
|Device||Browser||Unity (fps)||PlayCanvas (fps)|
|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.
- 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.
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.
12 thoughts on “PlayCanvas versus Unity WebGL”
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?
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)
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.
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.
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.
Comments are closed.