

HTML5 2D gaming performance analysis: Canvas 2D vs. WebGL vs. C++ - AshleysBrain
http://www.scirra.com/blog/58/html5-2d-gaming-performance-analysis

======
alexhaefner
I can speak to WebGL as we've actually built some stuff on top of it. Yes
performance is good, sometimes. But if your user is on hardware like Intel
X3100 graphics cards, then the WebGL context will run in software mode,
performance will be dismal, and you as a developer don't have any real checks
to see that.

Secondly, hardware support for WebGL is very dismal right now. For example,
newly shipping MacBook Air's don't support WebGL.

Third, we found so many inconsistencies across different hardware and
different browsers that it made it not worth it to work on a WebGL project for
the time being, especially for a small team. We wrote a number of runtime
checks, but we still could not account for all the bugs, or find ways around
every one of them.

If you're writing a new 2D game in HTML5 from scratch, you'll have a much
larger market share by going after a slightly simpler (artistically) game
using canvas, rather than trying to go for more horsepower with WebGL.
However, WebGL can be useful for porting, if you'd like to see an OpenGL game
you've already made come to the browser.

~~~
petercooper
_newly shipping MacBook Air's don't support WebGL._

How new? My MBA is only 2 or 3 months old and WebGL runs fine (and fast) under
Chrome 17. Indeed, under the test on the parent link, I get about 500 objects
on Canvas, 6000+ on WebGL.

~~~
alexhaefner
The latest generation wasn't working in my testing. Hmm, well as of Chrome
15/Firefox 7 they were not supported. Would you try out
<http://drawwith.me/demo> and let me know if that works?

~~~
jonmrodriguez
I have the Nov 2010 MacBook Air, and that demo works fine under both Firefox
7.0.1 and Chrome 15.0.874.121

------
fennecfoxen
"Finally it's a shame no mobiles support WebGL yet. iOS actually supports
WebGL, but they've disabled it! I'm not sure why they've done this, because
enabling WebGL is crucial to high performance HTML5 games on mobiles."

The cynic says: App store! App store! Money money money!

~~~
robterrell
Could be good reasons. Perhaps Apple's webGL implementation actually could be
used for exploits, and until it's secure they won't allow it for general use.
Notice the one place Apple does allow WebGL is iAds, which are reviewed &
controlled by Apple.

~~~
karl_nerd
This is what i was told by apple engineers when asking straight out.

------
extension
_if the renderer can leave the majority of the frame time free for game logic
to run, it's done its job. Consider it this way: Chrome 15 leaves 86% of the
frame time free and Classic leaves 97.6% of the frame time free_

Well, if you're going to evaluate it that way then surely you also have to
account for the game logic running much slower in JavaScript than in C++.

The bottom line is: If you care about graphics rendering, C++ wins by a large
margin. And if you care about game logic, C++ wins by an even bigger margin.

~~~
Game_Ender
A good part of game logic is done in a "scripting" language these days. For
example Lua is used in WoW & Starcraft 2 and the newer Civilization games use
Python. Generally they do use the core C++ engine to all the math heavy tasks
like collision detection.

~~~
betterth
And this obfuscates the point that many web games rely on scripting languages
on the server side to handle most tasks. You can't rely on the client to do
much game logic without (rightfully) being paranoid about the user themselves
interfering with what's in their active memory and that being sent back to
your server...

------
haberman
As a side note, if GPUs and CPUs are both _that awesome_ these days, why do
side-scrollers still not look perfect? I've been playing Braid on OS X and
while it's a pretty game, scrolling is just noticeably blurry (and this is on
a pimped-out MacBook Pro Core i5, NVIDIA GeForce GT 330M).

I've just always held out hope that once the hardware is fast enough, side-
scrollers would look just as crisp scrolling as they do standing still.

~~~
MrScruff
I'm pretty certain you're describing an effect of the display rather than the
GPU.

~~~
corysama
Yep. Ironically, the quality of the Macbook Pro's screen is what's causing the
problem. The Pro's IPS screen has much better color reproduction and view
angle consistency than the cheaper TN screens you see everywhere. However, a
disadvantage of IPS LCDs for games is a relatively slower color switching
speed. Hence, the blurriness during motion.

~~~
ricardobeat
MBPs do not have IPS displays, only the larger iMacs. Look at your screen from
a downward angle, you'll see it yellowing, look from above and light colors
are inverted.

And interestingly, most newer IPS panels have a gray-to-gray time similar to
TN, around 4ms (60fps = 16ms/frame). You can't tell anymore if a display is
good or not just by it's specs, each one is different.

~~~
corysama
I looked it up and you're right! That's a surprise to me. My buddies' pro has
significantly better color viewing angle than my macbook. I assumed it was an
s-ips or something similar.

~~~
ricardobeat
Yeah, I also believed they were IPS before buying mine :)

They seem like a slightly better TN, but still far away from IPS quality,
specially for photography/video.

------
udp
I wonder whether your huge[1] runtime had any effect on the benchmarks.
Wouldn't using pure Javascript have been a better idea?

I also notice your "C++" version used Direct3D. Shouldn't you have used OpenGL
with the exact same calls as the JS to get a fair comparison with the WebGL
versions?

[1] <http://www.scirra.com/labs/perftest-2d/c2runtime.js>

~~~
AshleysBrain
It's a 61kb script minified, and jQuery 1.7 is currently 91kb. Yes jQuery is
likely to be cached but IMO it's not huge, one of the game's images could
easily be 61kb too. On top of that we've seen some competing tools generating
like half a megabyte of JS :P

Edit: also our intent was to compare real game engines, which necessarily add
some performance overhead, rather than a thin experiment.

~~~
ricardobeat
I believe he was talking about execution speed (the overhead of the
framework), not download size.

------
aufreak3
Hmmm ... the author says that percentage of frame time left for game logic is
the important factor, but if raw c++ is around 6 times faster, doesn't that
mean you can do 6x more sophisticated game logic in a given amount of free
time as well?

That said, the webgl performance in chrome is indeed (relatively) impressive.
Am also a macbook air user and have no trouble getting good performance on it.

One point to note is that the webgl engine in chrome runs _all_ graphics in a
single process, atleast partly for reasons of security (shader code gets
checked by the browser before being set to the gpu, for example). That is sort
of like a driver on top of a driver and so there will always be like a 2x
performance gap between webgl and c++ i think.

Still ... the future looks bright.

~~~
marshray
For a given number of triangles/quads, you have a certain amount of time left
in the frame period for the game logic. Say 5 ms out of a 17 ms frame (@60
FPS). A faster language like C++ is going to take less time for feeding vertex
data to the GPU. So instead of taking 12 ms to push the vertices it may take 2
ms, giving you 15 ms for game logic instead of 5, a 3x increase in time.

The game logic will likely be faster by a similar factor, so you could quite
possibly get an 18x increase in game logic capacity.

------
petegrif
It would be interesting to see a NaCl implementation.

------
azakai
Why was the development version of Opera used, but not of the other browsers?
Both stable and development Opera is shown there, but just stable versions of
the other ones.

The development Opera does great, but the development versions of the other
browsers are likely also much faster than their stable versions.

~~~
evmar
It's only included in the last chart, with this explanation: "The Opera 12
alpha comes with hardware acceleration but since it's alpha I don't want to
include its results yet - sometimes making software more reliable also means
making it a little slower, and considering I used the stable branches for all
the other browsers I also thought it would be unfair to include Opera 12 alpha
(until the end where I throw it in for fun)."

~~~
azakai
Yes, I saw the explanation. But I think it would be more fun to include alpha
versions of the other browsers too :)

------
nitrogen
It seems that Canvas 2D isn't accelerated by Firefox 7 on Linux at all. I'm
only able to get about 600 objects, versus ~4200 with WebGL. Chrome's Canvas
settles at ~4200-4300 on the same system (WebGL does ~6100).

------
danmaz74
Very interesting analysis. Still, when comparing to C++, we have to consider
that with a game that actually _does_ something (game logic, interaction etc.)
C++ advantage would be much bigger.

~~~
rayiner
Actually C++ advantage would be smaller, since the test isn't at all GPU
bound. It's basically testing how fast you can copy data through the JS <->
C++ FFI into the GL library.

A test that stayed within JS would optimize better and perform better relative
to C++.

------
nextparadigms
I have a feeling they'll announce the Chrome port to Android at Google I/O
next year (which is also a Chrome event), and it might get WebGL support along
with it. I know some people were asking the devs about WebGL on Android at
last I/O, so they might've taken that into consideration for the next I/O.

It would be a good time to do it, too, because otherwise Mozilla and Opera
will do it anyway next year.

~~~
kevingadd
Firefox for android already implements webgl. of course, your phone's gpu may
not be up to the challenge.

------
Too
It would be interesting to see an svg comparison also. From my experience you
can crank out quite alot of scaling images there in newer browsers.

------
ccanassa
How come IE9 2D was faster than Chrome and Firefox?

------
rorrr
Your benchmark is obviously CPU bound, not GPU bound. That pretty much
invalidates this "analysis".

~~~
AshleysBrain
I made an effort to specifically highlight that in the conclusion.

