Speed and Memory – Final serious testing, I hope…

To be able to test canvas performance on mobile (and in more browsers), I changed my test page so that, instead of hardcoding my tests to do 1000 tiles per frame, the canvas would fit the whole screen, and the drawing simply covers the whole screen area, as many blits as that would take.
That means that “one test run” won’t do the same number of blits in my PC or in a mobile, and I technically can’t compare one to the other; however, that comparison doesn’t really mean anything anyway, and the amount of blitting I’ll need to do will be dependent on screen size too, so that’s fine.
I also added a nicer interface with a bunch of buttons to test everything in different ways and dump the results to a textarea (instead of my previous approach of using the console).

This is what I found (abridged to conclusions directly, without all the numbers, otherwise it was too long and boring):

Chrome 15 Firefox 8 iPhone 4 HTC Desire S
Baseline 62 FPS @ 1920×1080 (2294 blits per frame)

175 FPS @ 1024×768 (901 blits per frame)

123 FPS @ 1920×1079 (2263 blits per frame)

306 FPS @ 1024×768 (901 blits per frame)

66 FPS @ 480×320 (184 blits per frame) 34 FPS @ 800×400 (364 blits per frame)
Clearing the Screen FillRect a bit faster than clearRect.
Width trick is horrible.
Clearing the screen is the same as not clearing it.
Width trick is horrible.
Clearing the screen takes very little time.
Width trick is horrible.
Clearing the screen takes very little time.
Width trick is horrible.
Blit Source Large / Individual Individual, 5% faster Not much change Drawing from individual canvases is 5% slower than from a large sprite. However, when using toDataURL() images, drawing from individual images is even a bit faster. Individual canvases are the best case, 10% faster than the large sprite
Blit Source Type Canvas
Both images downloaded and toDataURL() images, 50% slower than blitting from canvas.
Images downloaded and toDataURL() images are just as fast. Canvas is impossibly slow (15-20x slower)
Images downloaded and toDataURL() images are just as fast. Also, individual images are faster than large canvas, so we should use this.
Images downloaded are 50% slower than blitting from canvas, just like in Chrome.
Drawing semi-transparent Exactly the same as opaque Exactly the same as opaque Exactly the same as opaque Exactly the same as opaque
Drawing off-limits About 4x faster Exactly the same as on-screen About 50% faster About 3x faster
Verdict Individual canvases Individual toDataURL() Individual toDataURL() Individual canvases


  • The baseline case is the closest to what I before referred to as “First drawing test”: blitting directly from the full sprite image, loaded from its URL, and clearing the screen with fillRect. Because of this, the Chrome numbers look horrible. Once you start drawing from canvas, you consistenly get twice the frame rate, and Firefox and Chrome are in the same ballpark. (Surprisingly close actually)
  • Firefox doesn’t get any faster when drawing off-limits. This means I can’t count on this speed-up, which was necessary in one of my laziness indulgement ideas…
  • Android and Chrome are unsurprisingly similar (particularly in the 50% slowdown from images). iPhone Safari, however, is quite different from Android Webkit.
  • I’m very pleasantly surprised at the performance of the HTC Desire! I expected the iPhone to be considerably faster, but the HTC is about twice as fast! That doesn’t seem to show in the table above, but those are the numbers before the 100% speedup from not using images, and also the iPhone is not in “retina mode”, so the HTC is actually drawing twice as much to screen and getting the same FPS. Awesome!
  • It’s a shame that I can’t use the same exact approach for everything. I’d rather have that than squeeze out a few more FPSs. However, canvas is slow in Firefox, and images are slow in Chrome, so there’s no way around it. That said, at least it’s not *too* different. I just have to crop the sprite files into individual cells on startup, and either keep them as canvases or convert them to images depending on the platform. Not too bad. Long live dynamic languages, I guess.

If you want to play around, here is the file I’ve been using. Look at the code to figure out what each button does. Please note that that code is crap, it’s ugly and doesn’t make much sense, I just threw that together quickly to test this. Also remember that that’ll only test the http:// case. Download the HTML file and the .png image it references and try the differences when running from file://.

If you find anything interesting, please do let me know!

One comment

  1. These are all so neat! I’m loving the dirfefent outlets for creativity. You’ve definitely opened my eyes. Creativity doesn’t have to be aesthetically deep. It’s about dirfefent perspectives and dirfefent ideas. I love it!xoxo,tiana of

Leave a Reply

Your email address will not be published. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre lang="" line="" escaped="" highlight="">