There’s been a lot of talk about whether Flash drains the battery on MacBooks as much as HTML5 does, so I thought I’d check this claim out. I’m concerned that any tests would be based upon Flash vs no Flash, without an HTML5 version to compare to.
So here we have identical content in Flash and HTML5. It’s just a simple 3D Particle system.
My challenge, leave this running and see which one runs down your battery fastest!
Now of course this will just be comparing one small part of Flash and HTML5 – rendering animating bitmap images. I’m sure that rich content will use the battery no matter which technology you use. But is there a difference in how fast it drains? And to be fair, please make sure you use the non-debug version of the FlashPlayer.
37 replies on “Flash uses more battery than HTML5?”
If you go back to the original Ars Technica article where this 2 hour claim came ( found here //arstechnica.com/apple/reviews/2010/11/the-future-of-notebooks-ars-reviews-the-11-macbook-air.ars/3 ) they say the following:
“With a handful of websites loaded in Safari, Flash-based ads kept the CPU running far more than seemed necessary, and the best time I recorded with Flash installed was just 4 hours. After deleting Flash, however, the MacBook Air ran for 6:02—with the exact same set of websites reloaded in Safari, and with static ads replacing the CPU-sucking Flash versions.”
So their test isn’t even HTML5 versus Flash, but static images versus animated Flash banner ads. In that case, Kevin Lynch is right, that no matter how much the Flash Player is optimized, animated content, possibly with video embedded into them for some ads, will never compare to static images. It just cannot be done. If it’s animated Flash content versus animated HTML5 Canvas, video tag and other content, then it makes a big more sense for these battery benchmarks.
Thanks Matt for that very useful information. I don’t read TechCrunch regularly so I’m surprised at the inaccuracies.
It’s normal for the life time of the battery to drop when you have more than one application running simultaneously. Flash Player does not have access to the video card and so the processor needs to work more intensively, which leads in higher energy consumption.
On my set-up. MacBook Pro 2.5Ghz, 4Gb RAM. Your Flash demo used approx. 65% processor. The HTML5 version used approx. 18%. Both demos were run in latest version of Chrome with it’s inbuilt Flash 10 plugin.
There is something wrong with the flash version, its very lagy, check your code.
HTML version seems ok.
I’ve checked the code, and although it could probably be optimised, it’s doing exactly the same thing using the same rendering techniques as the HTML5 version. I even rewrote it to use bitmaps rather than Flash display objects. (The HTML version could also be optimised that’s for sure!).
Great Idea! Maybe you could share the source so we can compare and contrast.
On my setup, Win7 64 bit, i5 @ 2.40×2, with 4 GB Ram and a Nvidia Optimus:
with integrated graphics:
Flash: 6~7% CPU
HTML: 5% CPU
with accelerated graphics:
Flash: 0% CPU
HTML: 5% CPU
I’m sorry, when I tested I forgot to close other browser windows that had some Flash ads. Here follows a new clean test:
with integrated graphics:
Flash: 5% CPU
HTML: 5% CPU
with accelerated graphics:
Flash: 0~1% CPU
HTML: 5% CPU
Reply
On my 3.5y old Dell Laptop (2GHz c2d) I get the following CPU usage results.
Flash Chrome: 25-30% CPU
Flash 64bit Square beta Internet Explorer: 10-15% CPU
HTML Chrome: 10-15% CPU
HTML Internet Explorer: :(%
MacBook Pro i5 15″
Flash Chrome: 66% CPU
HTML Chrome: 15% CPU
Flash Safari: 90% CPU 🙁
HTML Safari: 25% CPU
Both run ok on my Nexus1.
On my W7, 64 bit, core i7:
Flash, 1.01%
IE9 Beta – not supported (actually, is that right? Can you put in a link “try anyway”? The beta claims to have canvas support…
Re IE support, I’ll take a look at this later today.
Seb,
I like the idea of actually testing this out on different machines/browsers etc…Any chance you could log the user’s browser/OS and FPS info when they view the demos? That would provide substantially more information than people posting numbers in the comments.
Hi Todd, that’s a great idea! Sadly it would be quite involved to do this and I simply don’t have time. If you or anyone else would like to implement this let me know.
On my HTC Desire (Android 2.2) the HTML demo is more laggy than the flash demo.
hp EliteBook, Win 7, Intel core i5 m540
I also tested CPU usage playing movies on vimeo with Flash and HTML5 player. I stopped all unnecessary processes and rebooted my computer before each test.
Chrome:
– particles (flash): 10%
– particles (HTML5): 6%
– video (f): 15%
– video (H): 15%
While playing video with flash, the CPU usage was usually within +/-2% of the value with max. of 19% and min 8%. When using HTML5 player the CPU usage was extremely changed roughly every 20s with max 45% and min 2%.
Firefox:
– particles (f):12%
– particles (H):18%
IE 9:
– particles (f):8%
– video (f):10%
– video(H):9%
The same thing happened here. Flash had consistent CPU usage while the fluctuation happened with HTML5 player.
Is there a link to the source code? It’s difficult to test your claim that they are ‘doing exactly the same thing using the same rendering techniques’ without seeing the code.
You mean you don’t just blindly trust me? I’m offended! 😉 Source code has been added to the Flash page.
This is really interesting actually, because the first version of the code (posted ages ago here //sebleedelisle.com/2010/03/3d-engine-in-10-lines/) used the display list and Sprites with gradient vector graphics in it. It even uses a blur filter and color transform for the trails.
I rewrote it so that it just draw a bitmap image multiple times into a bitmap “canvas” as I really thought that would be faster. It doesn’t seem to be. So yes it does do exactly what the HTML5 canvas version does.
Like I said in my post though, neither version is especially optimised. But I have at least attempted to avoid bad practice, unlike this guy : //lab.simurai.com/html5/ads/
Hmmm… Do you think it would be useful to also compare both Flash versions: vectors in Sprites vs. bitmap?
I would be curious to see what, if any, actual performance differences there might be on various mobile phones, all battery questions aside.
I agree with one of your previous posts about how one of Flash’s strengths is low bandwidth vector animation, but I have heard that iPhone apps etc. run better with bitmaps. As I personally love Flash for its vectors, I would like to see such a close comparison.
An interesting study Seb!
Orion.
Head on over to //blog.iainlobb.com/2010/11/bunnylandmark-new-flash-game-benchmark.html where Iain has made a benchmark to test the difference between blitting and using the displaylist.
Oh there’s no doubt at all that mobiles perform better with bitmaps. I would still use vector graphics and convert to bitmaps at run time (although I hear this can be CPU intensive).
Seb
That’s excellent. Thanks Seb.
I guess I have to get on the blitting bandwagon!
on my nexoc e709 (geforce 9600gtx 1gb) html5 animation get twice of the ressource that flash ani needs.
chrome 9 -> html5 -> 82.000kb
chrome 9 -> flash -> 39.000kb
i was hoping before i started the tests, html5 will make it better.
Linux with NVidia drivers:
Flash (no GPU Acceleration): 40%,
HTML5 (Firefox): 50%,
HTML5 (Chrome 7): 56%
Flash clear winner //is.gd/gTGMz
Seems like there is no black and white.
OSX with FP 10.0
iMac 3.06Ghz
Idling Safari 5.0.2 5%
Flash +55%
HTML 5 +11%
Firefox 3.6.12
Flash – 42%
HTML5 – 45%
Chrome 7
Flash – 42%
HTML5 – 40%
However, I’m wondering if you’re going about this the wrong way. The traditional way to benchmark rendering is to measure the maximum FPS. Obviously if you can do more FPS, you are more efficient.
I would also like to see lot’s of other programmers make some benchmarks (not that I disagree with yours) to increase the sample size. There are so many different ways to measure performance, from vectors, to text handling to bitmaps to 3d operations that a single benchmark means nothing.
Hi Sam,
It’s not meant to be a benchmark (although the results are certainly interesting) as much as I’m examining whether rich HTML content runs down the battery as much as Flash does. The many many different browsers and environments would make a full benchmarking suite pretty difficult!
cheers
Seb
Your Flash version is poorly designed, you are redrawing the BitmapData canvas 200 times per frame in your updateParticles method. That’s just a silly design. If you redraw the BitmapData canvas once per updateParticles, you can already increase %CPU usage by about 60%.
//blog.leefernandes.com/particles
Even so the HTML version still uses about 3x less %CPU in Chrome 7, which is quite good. But you still have to take into consideration that straight code comparisons fail to consider that JS/HTML5 and Flash have different API’s that need to be treated differently. When you call .drawImage on the HTML5 canvas, I assume that it only redraws the specified image area of the canvas, whereas when you call .draw on the BitmapData object, it redraws the entire canvas.
Correction:
If you redraw the BitmapData canvas once per updateParticles, you can already *decrease %CPU usage by about 60%.
I’m not sure I understand what you mean? Can you post your source? The only thing I can think is that I forgot BitmapData.lock()…
Instead of calling the draw method inside of the for loop, via particle.render(), call it after the loop.
I got the 60% improvement on the Debug Player. With the regular Flash Player the CPU% drops about 25-30%
Hi reelfernandes,
I was honestly quite surprised the Flash version was so slow, it was certainly never my intention to “fan the fire” as you so bluntly put it!
I’ve rechecked and the Flash version does exactly the same as the HTML5 version in exactly the same way, and that is by design. In theory drawing bitmaps to another bitmap should be faster in Flash than drawing DisplayObjects into a bitmap (and without your source I can only assume that is what you are doing).
But my suspicions were right – I missed off the all-important BitmapData.lock() method, which will speed up draw methods on bitmaps that are visible on the stage. I’ve reinstated that and the Flash version has now improved considerably.
I’ll upload the new version shortly.
cheers!
Seb
Sounds good Seb! .lock() might be the best implementation. What improvement are you seeing with that?
I’m not sure how much of a speed benefit you get when using BitmapData.draw(). I understand you’re using this because of the scaling, but it’s not nearly as fast as BitmapData.copyPixels(). I’d be interested in seeing how this compares to just Shapes or even Shapes as the particles (for scaling) being drawn to a BitmapData.
Of course, being that there are a limited number of sizes possible for each, if it was really important to get the best performance, you could cache each size as a separate BitmapData in a list and just call copyPixels() on each of them in turn. But that changes what you’re trying to compare.
Isn’t this Javascript? From the look of the code, it appears everything you’re doing is in javascript. Should this be Javascript vs FLAsh? If this is the case of programming language then couldn’t you just say C++ vs Javascript vs Java .
EVery one does realise HTML5 code is infact only a few new supported (shitty) features to be used on Mobile devices right?
Everything I’m doing is JavaScript using the drawing API on an HTML5 canvas element context. I hope this helps to clarify.
Oh and, seriously, relax!
Javascript ≠ HTML5
Sorry. This Fails. and blows.