"HTML5" versus Flash: Animation Benchmarking

22 March 2010


A Blue Perspective:

I've written before about why you shouldn't let your current toolset dictate what it is you create and I still firmly hold to that mantra.

Some of my more recent work has revolved heavily around animation (real-time, interactive motion graphics, to be precise). When approaching such a project I don't have any particular technology in mind, but I do have a very exacting idea of what it should look like and how it should behave. Based upon that idea I can then choose how I want to do it.

A system which relies heavily on animation must make that animation convincing in order for the audience to be immersed in it. Choppy frame rates and jerky motion can make it an easy decision to close a tab, so the thing I find myself struggling with the most is performance. I would so desperately love to use native browser technologies to produce some of this stuff, but after years of comprimising my vision to fit into the browser I decided to become a bit more technology agnostic and author projects in whatever offers the best experience. Which – on the Web – means Flash.

In the couple of years since I made that decision though, browsers have taken huge strides in their ability to render graphics and animation. With HTML5 on the cusp of the mainstream, I decided to take another look at the technologies I'd shelved and see just how they perform against Flash.

Short version: Flash still wins, but browsers are catching up.

Long version: At the moment I can see 3 viable alternatives to Flash for animation: HTML, Canvas and SVG. Only Canvas is strictly HTML5, but since everyone's getting all hot about making web apps on the iPad with "HTML5" I thought I'd lump them all under that buzzword.

In order to test them against Flash I wrote a particle engine animation which is pretty easily translatable amongst all four technologies. They use roughly the same animation techniques, calculations, timers, etc. This allows us to get a framerate for each technology that we can compare with the others.

Tests for each of the technologies are here:

... and for each test you can vary the number of particles using a "particles" CGI parameter, like so:

You can also turn shadows on and off:

I ran each technology through a series of variations: 250, 500, 1000, 2000 & 4000 particles; different browsers; different OSes. And recorded the results. You can see the raw data at http://spreadsheets.google.com/ccc?key=0AuE1_QN_mm71dGlKaC16MmE4ZFRhXzVXQjcyUElpWGc&hl=en.

Although it's by no means scientific and I'm sure there's much more robust ways to benchmark this stuff, I began to see a general pattern emerging, one which is typified by my results for Firefox 3.6 on OS X:

Graph of results for animation benchmarking in Firefox 3.6 on OS X

Here are graphs of the other browser/OS combinations:

They all follow pretty much the same pattern: Flash on top, followed by Canvas, then HTML, then SVG; with the exception of Safari on OS X, where – at lower numbers of particles – the native browser technologies hold their own, but still degenerate in performance for higher numbers of particles.

It did actually surprise me how performant Canvas is and it also surprised me how crappy SVG is. Given these findings I'll probably again start using native browser technologies for less strenuous motion graphics (most probably using Canvas, even though interactivity in Canvas is a PITA). But for any heavy lifting Flash is still the go for the moment (depending upon its availability for the client environment).

If you'd like to run the benchmarks yourself and check the numbers, feel free to tell me your figures in the comments below. If you'd like to check out the code for all the tests, you can download them in one big ZIP. These tests are licensed under the LGPL.

Update (23/3/2010): For those whose browsers crash on the Flash test I have a feeling that the flood of setInterval calls might be causing it, so you can try the versions of the tests that are rate-limited to 25 FPS:

Update (19/5/2010): I just had word from Adobe that a bug in a version of their player will cause the Flash benchmark test to crash in some browsers. Upgrading to the latest player (10,0,45,2 or 10,1) should fix it.


, , , , , ,


  1. 1/76

    alex commented on 22 March 2010 @ 04:41

    The simple particle benchmark with flash crashed my firefox 3.6, so flahs is fast and fails fast :-). the svg was about 3-4 fps with firefox 3.6 and about 45fps!!! in the ie9 preview.

  2. 2/76

    Gleb Arestov commented on 22 March 2010 @ 05:23


  3. 3/76

    alex commented on 22 March 2010 @ 06:57

    gleb arestov ist absolutly right. you forgot the fastet browser on earth. opera is
    extemly fast in all testcases, only flash is crashing also opera (working on windows 7 and flash 10,0,12,36)

  4. 4/76

    Steve L commented on 22 March 2010 @ 08:25

    I have a head-ache

  5. 5/76

    clawsout commented on 22 March 2010 @ 08:51

    Hmmmm - Flash crashed both Firefox 3.6 and Safari 4.04 on a Windows XP machine - it did have a claimed frame rate of 299.99 (FF) and 384.34 (Safari) FPS at the time though!

    Just to add another browser/OS combination to the results:
    Safari 4.0.4 + Windows XP
    HTML = 23 FPS
    Canvas = 22 FPS
    SVG = 17 FPS

    My short version:
    The other three methods all worked without killing the browser - so Flash is in last place right below SVG in terms of performance.

  6. 6/76

    Jeff Schiller commented on 22 March 2010 @ 09:22

    The SVG results don't surprise me.

    I'd argue that SVG is not the best solution for particle effects, since you don't need a DOM element for each particle. Canvas is really suited well for something like this: lightweight JS objects that don't require mouse events.

  7. 7/76

    Jeff Schiller commented on 22 March 2010 @ 09:23

    John, I think you should also download the IE9 Platform Preview and give it a shot (obviously no canvas results there).

  8. 8/76

    Remy Sharp commented on 22 March 2010 @ 09:35

    Just ran your (downloaded) benchmarks in the IE9 platform preview.

    The tests all ran 500 particles, and have the following (approximate) fps:

    SVG: 30fps
    HTML: 25fps
    Canvas: 2.5-3fps (with excanvas) and eventually hung.

    There doesn't appear to be plugin support in the platform preview (which is understandable), so the flash didn't run (no doubt that'll be faster).

    I was running Windows 7 under Fusion on a Mac. The Windows OS had 1Gb of RAM and 1 CPU available if anyone was curious.

  9. 9/76

    gabel commented on 22 March 2010 @ 09:39

    Default Settings for Test
    Windows 7 64bit
    Firefox 3.6
    HTML 11 fps
    Canvas 28 fps
    SVG 3 fps
    Flash >100 fps

    IE 8 64bit
    HTML 25 fps
    Canvas 2-3 fps
    SVG n/a
    Flash n/a (white window)

    HTML 40 fps
    Canvas 52 fps
    SVG 26 fps
    Flash 80-100 fps

    Interesting how they differ. It seems performance is again just a matter of implementation.

  10. 10/76

    Joachim Rousseau commented on 22 March 2010 @ 09:45

    SVG is choppy on FF 3.6, but on my Ubuntu 9.10, Chromium 5 shows 50FPS.

    Same distro, Chromium shows 50 FPS with html version and 45FPS with canvas.
    Flash started ok, showing a strange 490FPS and stuck the browser aftrer a few seconds.

    Flash was 60FPS and stable in FF3.5 only.

    Conclusion :
    - Flash isn't the leader any more. Too unstable, not open enough for the web.
    - FF SVG engine is really poor
    - IE9 seems to keep its promises : very good gfx performances

  11. 11/76

    Jeff Schiller commented on 22 March 2010 @ 09:54

    Hi John,

    I just sent you an improved script for the SVG case that uses suspendRedraw() and unsuspendRedraw().


  12. 12/76

    Geoff Pack commented on 22 March 2010 @ 10:11

    Nice work.

    Ran the tests on my iPhone 3G:
    HTML: 0.75 fps
    Canvas:1.97 fps
    SVG: 1.18 fps
    Flash: --

    Also, could you do a Java / Processing version for comparison?

  13. 13/76

    Jeff Schiller commented on 22 March 2010 @ 11:09

    Actually decided to post techniques using SVG for this demo here: http://www.codedread.com/blog/archives/2010/03/22/know-the-beast/

  14. 14/76

    Lars Gunther commented on 22 March 2010 @ 21:51

    I've filed a bug with Mozilla on Firefox performance. https://bugzilla.mozilla.org/show_bug.cgi?id=554004

    Let's see what they say about it.

  15. 15/76

    Joshua Davis commented on 22 March 2010 @ 23:35

    What kind of buggy systems to people have that they complain all the time. I run many versions of browsers across many machines and no problems, no crashes, not ever. I'm sick of the whine bags.

    Nice tests!

  16. 16/76

    Joshua Davis commented on 22 March 2010 @ 23:35

    What kind of buggy systems to people have that they complain all the time. I run many versions of browsers across many machines and no problems, no crashes, not ever. I'm sick of the whine bags.

    Nice tests!

  17. 17/76

    Alfredo commented on 23 March 2010 @ 03:35

    I guess that the main problem with flash is that its a propitary protocol.

  18. 18/76

    clawsout commented on 23 March 2010 @ 10:00

    @Joshua Davis - not whining, and not running a buggy system - just stating a fact, running the Flash versions of the tests caused FF and Safari to crash - the others didn't. End of.

    Even if they didn't have spectacular frame-rates, at approximately 24 FPS (ie. the rate at which movies and tv are screened) there's no need for any higher speed. Thus, in this very particular example, I would say that the HTML and Canvas versions are the clear winners in that they are functional and fast enough.

    P.S. Nice double-post! Perhaps it was a bug in your system... :-)

  19. 19/76

    The Man in Blue commented on 23 March 2010 @ 11:38

    @Jeff Schiller: Thanks for the modified SVG code Jeff. I purposely didn't look at any optimsations for the various implementations, as I wanted a consistent, across the board benchmark for the same code. There's optimisations that you could do for each type of technology but I wanted to see how they perform with the same, fairly straight-forward technique.

  20. 20/76

    Sonny Burnett commented on 23 March 2010 @ 12:11

    The main problem with Flash is the amount of CPU cycles that it consumes vs. the other technologies, which makes it a killer for mobile devices.

    In its defense, it wasn't created for mobile computing. I don't think that Flash will clean up its code before the other technologies over take it.

    It is always preferable to have built in support vs. an add on. Look for flash to fade away by the end of 2011

  21. 21/76

    Jordan commented on 23 March 2010 @ 15:46

    There are some very big gains in Firefox's nightly builds canvas performance - I got it to beat Flash in a few cases. Though there are still the bad GC pauses. nightly.mozilla.org

  22. 22/76

    The Man in Blue commented on 23 March 2010 @ 19:40

    For those whose browsers crash on the Flash test I have a feeling that the flood of setInterval calls might be causing it, so you can try the versions of the tests that are rate-limited to 25 FPS. (At the end of the blog post above)

  23. 23/76

    Iain Collins commented on 24 March 2010 @ 02:41

    Very interesting, thanks for doing this.

    For reference on a 2.8 Ghz Core 2 Duo at 1920x1080 running Safari on Mac OS 10.6 canvas outperforms Flash noticeably - both in reported FPS and apparent smoothness (HTML and SVG reported similar framerates as canvas and flash, but actually they were somewhat choppy).

    However, with shadows enabled the Flash FPS stays stable while canvas framerates takes a nosedive (both reported FPS value and visually).

  24. 24/76

    clawsout commented on 24 March 2010 @ 09:44

    @The Man in Blue - yes, it must have been the setInterval calls, because a test of the rate-limited 25FPS Flash versions worked fine in both Firefox and Safari on XP. And Flash is indeeed marginally faster than Canvas and significantly faster than HTML and SVG.

  25. 25/76

    Andrew K commented on 24 March 2010 @ 11:23

    Umm... http://www.youtube.com/watch?v=D27r1qiPC-8

  26. 26/76

    Andrew commented on 24 March 2010 @ 18:12

    Man, HTML5 sucked major balls in those tests 5fps compared to the 70fps from flash.

    Flash didn't crash once in any of the browsers I tested (chrome 5, ff3.6) so maybe you all have computer AIDS or some shit.

  27. 27/76

    jimik commented on 24 March 2010 @ 23:17

    hmm :-)
    canvas: 60
    chrome, ubuntu 64b

  28. 28/76

    Zachary Bennett commented on 25 March 2010 @ 19:50

    Why didn't you involve a Linux test?

  29. 29/76

    Mario Klingemann commented on 25 March 2010 @ 20:01

    I had a quick look at the source you used for the Flash test and I must say that your approach is not really the best possible. Quite the contrary. It looks like you are using JavaScript-style programming in ActionScript.

    First of all, if you are doing an animation you do not want to use setTimeout(animate, 1) - you should listen to the onEnterFrame event instead and set the swf framerate to the maximum.

    The next problem is that you are not typing any of your variables - this will slow down everything a lot especially if you are using this for particles where this is duplicated a few thousand times. Actually your Particle is not even a real class but some kind of strange nested function.

    Really - if you want to compare Flash to JavaScript performance please use some real-world ActionScript.

  30. 30/76

    cedricv commented on 25 March 2010 @ 20:10

    On 64-bit Linux with Chrome 5.0.307.11 :

    WINNER: Canvas ~64FPS

    Flash, HTML and SVG all get ~40FPS

  31. 31/76

    Jaspio commented on 25 March 2010 @ 20:16

    My test results at 500 particles:

    Chrome 4.1.249 / Windows 7 x64
    HTLM+JS27-30 fps
    Canvas30 fps
    SVG25-28 fps
    Flash64-72 fps

    IE 8 / Windows 7 x64
    HTML+JS24 fps
    Canvas(js)2.6 fps
    Flash64-68 fps

    Firefox 3.6.2 / Windows 7 x64
    HTLM+JS11.6-11.8 fps
    SVG3 fps
    Flash102 - 140 fps

    I believe I have some plugin issues in Firefox ;)

  32. 32/76

    Jpvincent commented on 25 March 2010 @ 20:59

    The latest Flash version uses hardware acceleration very well, whereas the current browser implementations dont
    Can you benchmark the IE9 preview who promises to use hardware acceleration ?

  33. 33/76

    Robin commented on 25 March 2010 @ 21:21

    Not sure how you performed these tests, but the Flash version maxes out at around 22-23 FPS on my 2.2ghz Macbook, and both the Canvas and the HTML version hits the exact same framerate - and I have nothing running in the background to mess things up.

    Another detail you left out here is the amount of processing power needed for these tests - despite same framerate, the Flash version eats almost 100% of one CPU core, while the Canvas version eats about 40%. This matters a whole lot in the full equation as well.

  34. 34/76

    marcus commented on 25 March 2010 @ 21:24

    i know nitpicking isn't always right, but i still think it's of value: your html/js code is awfully inefficient. the exact same effect you coded here, i can improve to run about twice as fast - if not more - still being html/js. ergo, your benchmarks are more than a bit deceiving.

  35. 35/76

    marcus commented on 25 March 2010 @ 21:24

    i know nitpicking isn't always right, but i still think it's of value: your html/js code is awfully inefficient. the exact same effect you coded here, i can improve to run about twice as fast - if not more - still being html/js. ergo, your benchmarks are more than a bit deceiving.

  36. 36/76

    julien commented on 25 March 2010 @ 21:33

    No wonder your Flash tests are slower than HTML5, looking at the (pseudo actionscript) code made me understand

  37. 37/76

    Indyaner commented on 25 March 2010 @ 21:47

    My Stats (Win7 x64, FF 3.0 Portable, Flash 10)

    HTML 12
    Canvas 8
    SVG 4
    Flash 108

    1000 Particle, Shadow=true
    Canvas 5 (but Shadows wernt visible)
    SVG <1
    Flash 60

  38. 38/76

    andreas commented on 25 March 2010 @ 21:53

    checking your javascript code it is obvious you are the "software engineer" and not the programmer. this code could be about 10 times faster, 10 times shorter.

  39. 39/76

    Michael Christensen commented on 25 March 2010 @ 22:19

    Regular DHTML runs so much faster than the others in Chrome.


    That is pretty amazing - so in some tests DHTML is SO much faster than flash/flex/java.

    Amazing but true.

  40. 40/76

    zdbzd commented on 25 March 2010 @ 22:33

    My Stats (Ubuntu 8.10 64bit, Google Chrome 5, Flash 10)

    500 particles

    HTML: 50
    CANVAS: 85
    SVG: 55
    FLASH: 50

    I suspect this has as much to do with Linux flash being slow as it does with Chrome being fast

  41. 41/76

    Matthew commented on 25 March 2010 @ 23:07

    I agree with zdbzd, they all run very fast with chrome in Ubuntu, flash sucks as usual though.

  42. 42/76

    Brandon commented on 25 March 2010 @ 23:43

    Wow.. people really seem to be hating on Flash. Let's see if the other technologies can do something like this: http://ecodazoo.com/


  43. 43/76

    Matthew Nuzum commented on 26 March 2010 @ 00:01

    On my test Flash had the highest frame rate but it was not the smoothest animation. There was a few points where it was choppy and stuttered. Canvas had a lower frame rate but was still in the high 20's and low 30's (making it plenty fast imho) and did not stutter or drop frames that I could see.

    This is exciting results. Thanks for the write up.

  44. 44/76

    gren commented on 26 March 2010 @ 00:14

    I agree. The canvas version is more efficient than the flash version on linux (due to the bad flash plugin on linux).

    @Brandon, with WebGL, 3D will be possible ;) Let's wait.

    I think flash is going to disappear for standard web use (like for carousel, ads, small animations, video (video tag) ...) but maybe not for more specific use (like games, etc).

    Best regards,

  45. 45/76

    Tom commented on 26 March 2010 @ 00:24

    No mention of upcoming hardware acceleration for "HTML5", or browser advances (threads, use of multiple CPU cores, use of GPU)?

    I'd say that HTML will carry on increasing it's speed and capabilities

  46. 46/76

    Anas commented on 26 March 2010 @ 00:40

    flash is working really great and really smooth, started with about 300 fps then went down and kept the =~ 120 fps

    the rest was really slow . only the html was about max 24 fps even alittle less, which is the minimum for a standard animation.

    so Flash wins !

    tested on win7 64bit

  47. 47/76

    OLL commented on 26 March 2010 @ 00:52

    My results on Windows 7 64bit:

    Chrome: 40fps

  48. 48/76

    Kumar commented on 26 March 2010 @ 00:59

    Strange that the 1000 particle test declares that it is running at 45fps on flash and at about 23fps using canvas, but the latter *looks* smoother. I'm using Chrome 5.0.307.11 beta on MacOSX.

  49. 49/76

    KK commented on 26 March 2010 @ 01:41

    Flash crashed FF on WinXP, it ran the 25 fps well , I guess you should change your tl;dr to Flash still fastest but buggy

  50. 50/76

    Albert commented on 26 March 2010 @ 01:42

    On my system (Chrome on MacOSX), the difference is not really that much. With unlimited FPS, Flash has about 40FPS and the others in the range of 25-35FPS.

    What I find more important in this debate is the resources each solution takes. I really hate it when my browser makes my whole system slow. Esp. when surfing with multiple tabs.

    And Flash is clearly the worst. Not only that it takes most CPU power of all the solutions, it also produces some high IO-usage on my system.

    The other three solutions are all better in this respect. The canvas solutions seems to win.

  51. 51/76

    Bowser commented on 26 March 2010 @ 01:54

    This is cool analysis. Could you consider adding a set of popular browsers (that support html5 et al) on the third dimension of the FPS vs Particles graph? Thanks!

  52. 52/76

    Schepp commented on 26 March 2010 @ 07:32

    I did a bench on my DirectX-11-powered Windows 7 x64 system.

    My distilled findings:
    - Opera 10.51 is damn fast, wins in HTML and Canvas
    - Flash 10.1 beta 3 is reeeeeally fast (GPU-acceleration?)
    - Flash (10.1?) is a lot slower only on Chrome

    System and Benchmarks Specs
    Intel Core i7 860 at standard clocks (Quadcore 2.8GHz)
    8 Gigs of RAM
    ATI Radeon 5770 (DirectX-11)
    Windows 7 x64
    Flash 10.1 beta3 (, GPU-accelerated)
    All benchs run in maximized browser-window under 1920 x 1200

    IE9 (GPU-accelerated)
    Flash 250+
    HTML 37
    SVG 47
    Canvas N/A

    Firefox 3.6.2
    Flash 250+
    HTML 7.4
    SVG 2.5
    Canvas 33

    Firefox 3.7a4pre (GPU-acceleration activated in about:config)
    Flash 250+
    HTML 13.8
    SVG 2.75
    Canvas 32

    Flash 90 - 120 (jumpy)
    HTML 38
    SVG 33
    Canvas 53

    Safari 4
    Flash 250+
    HTML 35
    SVG 43 (bug: only visible while holding a key pressed)
    Canvas 50 (bug: only visible while holding a key pressed)

    Opera 10.51
    Flash 250+
    HTML 75
    SVG 25
    Canvas 69



  53. 53/76

    Dan commented on 26 March 2010 @ 08:25

    Like every piece of code in this world, it matters how it's written, especially when dealing with graphics and animation. Looks like the code could be
    tweaked for all versions. Good idea, but to be a real comparison, each would have to be optimized by the appropriate platform expert.

  54. 54/76

    Stephen commented on 26 March 2010 @ 12:59

    You say Canvas is "performant" but you really mean it's fast, don't you?

  55. 55/76

    FlashGordon commented on 26 March 2010 @ 15:52

    Wow, some serious Flash hating going on there. Flash never crashed and the other three made the browser (FF3.6) go syrupy.

  56. 56/76

    BobSmith commented on 26 March 2010 @ 22:51

    You forgot to factor in the time necessary to download and install Flash. Then the time to patch it every time someone exploits a security hole (which seems to happen just about every week). Add those to your graph and Flash will be at the very bottom.

  57. 57/76

    MajorKoopa commented on 27 March 2010 @ 02:32

    (on my hardware, may vary) Flash and Canvas were the only ones not to drop the frame rate when I moved my mouse around.

  58. 58/76

    Michael Chaize commented on 27 March 2010 @ 02:57

    great benchmark.
    Can you share the code used for the Flash sample ? There are numerous ways to optimize Flash animations thanks to the Flash API. Here is a common method:

  59. 59/76

    Craig Babcock commented on 27 March 2010 @ 07:42

    As others have pointed out, the code for these tests could be greatly optimized. To get more accurate results, it might be a good idea to pose this as a benchmarking challenge. Experts (some of whom have already chimed in) could submit better code. Then, the results would have some comparative value.

  60. 60/76

    Minh Tran commented on 27 March 2010 @ 13:31

    mine is: (mac 10.5.8, core 2@2.6Ghz)
    on FF3.6:
    flash 26 FPS, canvas: 16FPS, svg: 2FPS
    chrome: flash 26, canvas, 13-15,svg:14

  61. 61/76

    Alex commented on 27 March 2010 @ 21:17

    Tried it on Debian Linux, Core2Quad 8400:

    On Firefox (Iceweasel 3.5.8):
    HTML: 5 fps
    Canvas: 23 fps
    SVG: 4fps
    Flash: 90-100 fps

    On Epiphany (Webkit):
    HTML: 35 fps
    Canvas: 9 fps
    SVG: 23 fps
    Flash: doesn't work, blank screen

    On Galeon (Mozilla):
    HTML: 13 fps
    Canvas: 17 fps
    SVG: 4 fps
    Flash: 30 fps

    Interesting...! :)

  62. 62/76

    Faktura VAT commented on 28 March 2010 @ 19:18

    mine is: (ubuntu 9.10, core 2@2.4Ghz)
    on FF3.5:
    flash 25 FPS, canvas: 16FPS, svg: 2FPS
    chrome: flash 26, canvas, 12-15,svg:13

  63. 63/76

    Andy commented on 29 March 2010 @ 12:15

    I understand that you wanted an approximately consistent comparison, but flooding the Flash version with setInterval(1) is just abusive - it's trying to get Flash to run the draw routine between screen refreshes.

    What you want is for the draw routine to fire every frame, and the way to do that is with an ENTER_FRAME event listener.
    addEventListener( Event.ENTER_FRAME, animate );

  64. 64/76

    Mikael commented on 29 March 2010 @ 17:45

    @brandon: Yea really great...

    TypeError: Error #1009: Cannot access a property or method of a null object reference.
    at SoundManager/opening()
    at Foot/inStage()
    at M3D_controller/startYou()
    at loader_fla::MainTimeline/inited2()
    at MethodInfo-34()

  65. 65/76

    Web Tasarim commented on 29 March 2010 @ 21:58

    Nice... I think it's good to see that there will be some alternatives to flash in the future when it comes to "flashy" design. Browsers are indeed catching up and canvas & svg will be the new way to implement vectors and good animations in sometime soon. Even currently, with jQuery you can create some flash-like animations :)

    But it's no excuse for not including flash support in iPad. It's gay. (I know i digress but it pisses me off :P )

  66. 66/76

    Anksiyete commented on 29 March 2010 @ 22:45

    Really nice Cameron. It's great to see new technologies coming over flash dominance. It will be great to have some alternatives than flash when creating some neat animations. Although i think i heard they will be a little harder to implement.

    P.S.: That flash thing didn't crash on me and it was so awsome to watch with 100+ fps! :)

  67. 67/76

    lala :] commented on 30 March 2010 @ 04:33


  68. 68/76

    Web Design Los Angeles commented on 30 March 2010 @ 08:26

    Awesome post. I definitely like flashy sites. J query is really good too.

  69. 69/76

    skymeh commented on 30 March 2010 @ 15:55

    Flash eats the others for breakfast. No crashes here with Firefox 3.5 on Windows.

    HTML5 and the others chug along like an old granny.

  70. 70/76

    Ken Kozak commented on 31 March 2010 @ 04:32

    FPS isn't everything. On my Mac laptop (OS X 10.5.8), running in Safari 4.0.5 and Firefox 3.6, Flash had a faster FPS, but they all seemed a bit choppy.

    When running on Chrome Beta however (5.0.342.7 beta), FPS speeds were about the same, but Canvas was by far the smoothest of all.

    I for one like Flash, but I think the limitation on my end is that Adobe's Flash implementation on the Mac platform is terrible, and it's the main reason my browser crashes. If I was running a PC, I think for now I'd stick with Flash.

  71. 71/76

    MichaŽl Chaize commented on 31 March 2010 @ 06:57


    I've just run the scripts on a Google Nexus One with a prerelease of Flash Player 10.1 installed on it. The trends are quite the same as on my MAC.

    Look at my video:

  72. 72/76

    encoder commented on 31 March 2010 @ 20:19

    in the mean time i just figured out why jobs started the whole html vs flash thing. and i believe he is actually paying people to feed the fire, in order to attenuate the glow of the black point right to "it still does not support flash".

    what if - for ex. - iPhone's safari would support flash.

    apple is selling a ton of small games and applications for these devices, he the revenue is split between apple and the developer, and it is a multimillion dollar business, just the games.
    there are great sites out there like newgrounds and kongregate with millions of greater games that you just can't buy on appstore.

    so if you flash iPhone up, no one in there right mind will buy a game from apple, if they have access to millions of them for free. apple will lose a big chunk of money.
    and there will be also apps in flash that do just anything for free.

    implementing the Air run-time is much safer. adobe gets it's share, apple get's it's share, and everyone is happy, except the developer, but the platform will be used anyway, at least i will try it out because there are many more ways to make money of iPhone/pad users.

    iPhone and iPad will not support flash in their browsers because apple wants your money.

    i brought this up because the whole flash vs html5 was started by jobs. i am fully aware that the iphone/ipad users who actively browse the web is an irrelevant number.

  73. 73/76

    arbaz commented on 2 April 2010 @ 23:01

    i have worked on flash for few months but then i shifted to silver light, i want to know more about HTML5 with silver light, can you please write a post on it?

  74. 74/76

    Sirkkasart commented on 3 April 2010 @ 00:36

    Great post, flash can be so versatile.

  75. 75/76

    Gunnar Andreassen commented on 3 April 2010 @ 07:56

    Flash rules - but only use it when needed.

  76. 76/76

    James Moralde commented on 4 April 2010 @ 11:45

    Would implementing Jeff's modification (e.g. attaching the circle to the DOM only after the element is initialized) on his SVG test on all of them (HTML, Flash and Canvas) change the order of efficiency?

  77. Leave your own comment

    Comments have been turned off on this entry to foil the demons from the lower pits of Spamzalot.

    If you've got some vitriol that just has to be spat, then contact me.

Follow me on Twitter

To hear smaller but more regular stuff from me, follow @themaninblue.

Monthly Archives

Popular Entries

My Book: Simply JavaScript

Simply JavaScript

Simply JavaScript is an enjoyable and easy-to-follow guide for beginners as they begin their journey into JavaScript. Separated into 9 logical chapters, it will take you all the way from the basics of the JavaScript language through to DOM manipulation and Ajax.

Step-by-step examples, rich illustrations and humourous commentary will teach you the right way to code JavaScript in both an unobtrusive and an accessible manner.

RSS feed