Flash Outperforms HTML5 on Mobile Devices

Posted on by

***Another Update: I’ve created a new post with a more complex animation and have also included SVG into the mix: http://www.blackcj.com/blog/2010/09/22/canvas-flash-and-svg-mobile-comparison/ ***

***Update: I’m already three steps ahead of this article. I have already received / analyzed the optimized JS in a later post. Please read all four articles on this topic before replying or your comment will be filtered. Thanks!***

Anybody notice a re-occurring theme here? Canvas performance on the new iPod Touch and iPhone 4G is laughable at 22FPS rendering simple animation. At least the Nexus One can muster up a decent 40FPS for basic canvas rendering. Flash Player 10.1 on the other hand, blows HTML5 out of the water running at 57FPS on the Nexus One! Let’s not forget to mention that HTML5 consumed TWICE the battery life as Flash for these tests on the Android. Unfortunately, Steve doesn’t want me to know the exact battery life on my iPod Touch so it wasn’t included in that part of the testing.

All of these test were done by benchmarking in browser performance. Native applications using AIR for Android yields even better performance but we’ll leave that for the day when HTML5 can export to an APK (native Android app).

Let’s take a peek at some live footage:

Frame rate comparison:

Keep in mind Flash Player 10.1 is relatively new. If Flash had been included with the original iPhone, you would have hated it. The new version, however, kicks ass. Would love to see some hacked iPhone Flash benchmarks to fill in the missing pieces on the above graph. If the iOS can’t render a little ball, HTML5 is going to be a hard sell for iDevices.

Why do we need 57FPS? Most web content targets 30FPS.The human eye really can’t differentiate after about 30FPS. Well, this is a single object rendered on the screen. Add some game logic, additional balls maybe a graphic and you’ll quickly find the 24FPS on the iPod dip down below 15. Having extra CPU cycles to do other things allows developers to target 30FPS when building games and animations.

Battery consumption after 10 minutes:

***Addition: The graph above is in percentage of batter drained after 10 minutes of animation during airplane mode (no cell or internet traffic to get in the way). A bit more crude than the first graph but I really didn’t want to sit around all afternoon waiting for my battery to drain. I’ll try to post some more battery data soon. The most important note is that Flash didn’t consume more battery than HTML5, which was counter to my initial hypothesis.***

This graph explains itself. Canvas consumes more battery power than Flash. It’s amazing that Flash can render something at 57FPS in half the battery power than it takes canvas to run at 40FPS.

Try it out:
HTML5 (JavaScript):
http://www.blackcj.com/blog/wp-content/jsdemos/BallBounce/

Flash (ActionScript):
http://www.blackcj.com/blog/wp-content/swfs/BallBounce/

Conclusion:
HTML5 will sit side by side with Flash. Gradient fonts, drop shadows, basic video and simple transitions are probably better suited for HTML5. When it comes to rendering display objects, animation and digital rights management for video, it would be silly not to use Flash. But wait Chris, HTML5 performance is going to get better! I’ll believe it when I see it. Adobe continues to raise the bar and it will be an uphill battle to catch up.

Graphs created using this tool:
http://nces.ed.gov/nceskids/createAgraph/

Afterthought:
I’m actually quite satisfied with the HTML5 canvas for Android. It will probably work for what I was planning to do. After the iOS exporter in CS5 failed to produce quality animation results, I was hoping for more from HTML5. Basically, I feel stuck having to code in Objective-C just to hit the iOS folks out there. This essentially ruined some of my plans for creating a game framework that runs Box2D cross platform. It basically made my purchase of an iPod Touch rather worthless. Unless Apple steps up I’m going to have to exclude iOS devices from my demos or re-code everything in a third language. The whole point is not to have to re-create the same code for every device in a different language.

Post to TwitPic from Flash / Flex

Posted on by

Problem:
TwitPic has a restricted crossdomain.xml file preventing your Flash web applications from posting directly to the service.

Solution:
Create a simple PHP script to proxy the request through a server that you do have access to!

Here is the code:

<?php
  $post_tweet_url='http://twitpic.com/api/uploadAndPost';
  $file=$_FILES['media'];
  $postfields = array();
  $postfields['username'] = $_POST['username'];
  $postfields['password'] = $_POST['password'];
  $postfields['message'] = $_POST['message'];
  $postfields['media'] = "@$file[tmp_name]";
  $curl = curl_init();
  curl_setopt($curl, CURLOPT_CONNECTTIMEOUT, 2);
  curl_setopt($curl, CURLOPT_HEADER, false);
  curl_setopt($curl, CURLOPT_RETURNTRANSFER, 1);
  curl_setopt($curl, CURLOPT_BINARYTRANSFER, 1);
  curl_setopt($curl, CURLOPT_URL, $post_tweet_url);
  curl_setopt($curl, CURLOPT_POST, 3);
  curl_setopt($curl, CURLOPT_POSTFIELDS, $postfields);
  $result = curl_exec($curl);
  curl_close($curl);
  header ("content-type: text/xml");
  echo $result ;
?>

Just create a PHP file with the contents above and replace the post URL from my previous example with the path to this script.

Enjoy!

Top Tweets for September 15

Posted on by

64bit Flash Player in beta, free Android UI PSD, HTML5 in Illustrator and more! Thought I’d share some of these resources from Twitter with the rest of the world.

@adobeflash: Flash Player 64-bit preview now available on Labs! http://bit.ly/33QVDY

@gskinner: Just posted the 2nd article in my series on Creating Great Developers. This one focuses on hiring. http://is.gd/fc2Os

@Influxis: ALERT! New Influxis 2-to-many video chat app dev’d by @JerryChabolla called FACES! http://labs.influxis.com/?p=1206

@weberdesignlabs: 35 Free Fonts for Elegant Corporate Designs – http://ow.ly/2ENFC – 15 Best Social Icons Sets – http://ow.ly/2ENCb

@360Flex: sweet! RT @jonmacdonald: Android designers can also find an Android GUI PSD here: http://bit.ly/c02lpi

@seb_ly: as ever, intelligent report from @guardiantech re the html5 canvas game biolab http://bit.ly/drPT7T

@FITC: HTML5 in Adobe Illustrator?! Why yes, now there is! http://ow.ly/2EJyW

Enjoy!

What to Expect from the iPhone Exporter

Posted on by

In light of recent news I decided to port over some of my AIR for Android demos to iOS. Apple developer registration process aside, I was surprised at how easy it was to publish the same apps for both platforms. The code for all three examples worked unchanged from the Android optimized version. Here is an overview:

The Good:
Same code works on both devices!
Develop iOS apps on a PC.
Performance is good for simple animation and logic.

The Bad:
Box2D tanks through the exporter even with GPU acceleration, 17fps iOS vs 30fps Android.
File size is crazy big, my demo went from 3KB to 7MB.

The Ugly:
Registration for iOS development is a pain in the ass.
Exporting from Flash for iOS takes significantly longer than Android, minutes instead of seconds.

General Observations:
Colors differ slightly between the devices, iOS is lighter than Android.
Resolution through the exporter is currently locked at 480 by 320, which will hopefully change soon.

Summary:
The exporter works well for simple applications but don’t expect to get real life physics. Performance on native AIR for Android is significantly better. The savings you’ll get from developing once and deploying to multiple devices is HUGE. Just make sure your expectations are on par with actual performance or you’ll be re-coding in Objective-C.