I asked in my last post if Adobe’s focus on mobile would limit the features we’d see in future versions of Flash. Well looks like I have an answer via Thibault Imbert’s blog where he teases us all with talk of Flash’s next generation 3D API.

For those wanting to know more, Flash Player engineer Sebastian Marketsmueller will be holding a session at Adobe MAX 2010 where he’ll delve deep into Flash 3D. So just how sophisticated is Flash’s 3D support going to be? Well I guess we’ll need to wait and see but without giving much away Thibault promises that some serious stuff is coming for 3D developers.

You can find a schedule for this years MAX sessions here.

There’s a really interesting post over on the YouTube API Blog from Google’s YouTube team explaining their reasons for using the Flash Platform to deliver video.

The article discusses the advantages Flash currently has over the HTML5 <video> tag including:

• A Standardised Video Format
• Robust Video Streaming
• Content Protection
• Encapsulation & Embedding of Video
• Fullscreen Support
• Camera and Microphone access

It’s definitely worth your while reading through the article and I’ll leave you with this quote, which I think sums things up nicely.

Today, Adobe Flash provides the best platform for YouTube’s video distribution requirements, which is why our primary video player is built with it.

I keep hearing from friends and colleagues that Flash is notoriously slow and the content it produces is hopelessly bloated. Of course this simply isn’t true but recently I’ve been finding out the hard way that it’s not easy to convince many of them otherwise.

Now I’m not attempting to turn this into a Flash v HTML5 debate but I do believe that some of these misconceptions have been borne out from the war that has erupted between those who support Flash and those who want it gone. However I feel most of the blame lies with those who use Flash and I do confess to being as guilty as the next man when it comes to writing large SWFs that use poor loading strategies.

It is all too easy to create unnecessarily large SWFs by producing hopelessly large vector images, packing your SWF with high-quality bitmaps, and forcing all your code and resources to load up-front. Ignore everything that’s great about Flash and you’ll soon have users yawning as they wait for the entire SWF to download before they’re able to try out your latest masterpiece.

So in an attempt to re-educate many of the non-Flash developers at WeeWorld I set myself the task of ensuring that any Flash content produced for our latest project would be as small as possible without a loss of perceived quality.

But first we had to decide if Flash was required at all. From the initial mock-ups it was clear that HTML, JavaScript and some server-side cleverness would take care of the majority. There was however one section right in the centre of the page that was screaming out to be done in Flash (or at least that’s what I believed).

Hey! I want to be Flash!!!

The centre panel in the mock-up above represents a little voting game where users get to vote for their favourite WeeMees during a fashion contest. Each time the user votes a new WeeMee is loaded from the server and slides into view. After voting, a panel is updated showing the current voting statistics for that WeeMee. To ensure the voting experience was as fluid as possible we decided to cache WeeMee SWFs up-front to reduce loading time between votes.

First I had to justify it. After all, some team members quite rightly stated that it could probably be done in JavaScript. In the end though we went with Flash for the following reasons.

• We’d need to load WeeMees, which are all dynamically generated on our server as SWFs.
• Flash would give us good cross-browser support without the need for any browser-specific code.
• The visuals could easily be reproduced using Flash’s vector drawing tools.
• The vector content would be a fraction of the size of bitmaps.
• ActionScript is compiled into a compact byte-code without sacrificing the legibility of the source.
• I moaned at my boss MacDog for two weeks straight until he relented.

So how did I get on? Well in the end I split the project into two SWFs – a preloader SWF and the main SWF. The preloader came in at 4K with the other being around 12K. The combined total was a minuscule 16K! To be honest given the tiny file size it was perhaps overkill having a preloader but heh, I’d rather the user had to wait for 4K to download before seeing something rather than 12K.

The point of the preloader wasn’t to actually feedback to the user how much of the content had loaded – after all everything loaded too quickly for there to be such a need. Instead it was created to force a visual onto the screen as quickly as possible therefore giving the user the perception that the content had loaded. I was eager to, as quickly as possible, plug the hole in the HTML page where the Flash content would be rendered, and the preloader gave me that opportunity.

High level breakdown of SWFs.

The diagram above shows roughly how each SWF looks and more importantly a high-level breakdown of sizes. The preloader’s (left hand-side) content is more-or-less split 50-50 by code and embedded fonts. The final size of the graphics within the preloader was perhaps the most pleasing, with the vector content only consuming 185 bytes!

It was a similar story with the main SWF (right hand-side). The ActionScript consumed the majority of the file size while the graphics consumed next to nothing. This time the vector artwork was a little larger but still comfortably under a kilobyte, coming in at 479 bytes. Unlike the preloader I was able to use device fonts for the main SWF, further helping to reduce the final SWF size.

I could quite easily reduce the total SWF size further by spending time shortening function and variable names. There are of course many other ways to squeeze the code down but I was eager to keep it as legible and maintainable as possible. The total size of the ActionScript source across both SWFs was 41K but was reduced to 13K after compilation.

I’m happy with the result along with everyone else at WeeWorld. Many were pleasantly surprised at the final SWF sizes and hopefully it has gone a long way towards making individuals realise that there’s absolutely nothing wrong with the Flash Player or the SWF format.

If you want to keep file sizes down I’d suggest you spend as much time and effort optimising your vector content – it’s certainly where the majority of savings were made on this project. Where possible re-use content by storing your artwork in movie clips and using instances of those clips. In fact take a look at the diagram below for a more in-depth breakdown of the vector graphics used within the SWFs.

Size breakdown across SWFs.

Also spend time thinking about your font usage. Only embed fonts if you really must. Where possible use device fonts, which will help reduce significantly the final size of your SWF. And although it wasn’t an issue with this project, if you find your byte-code size getting out of hand then you many want to split your code into separate libraries and load them at run-time when needed.

If you’re still in any doubt as to the compactness of the SWF format then perhaps this might give you some context. I examined the size of a single JPEG (260 x 274 pixels) loaded onto the front page of the WeeWorld site. It was a fairly compact 31K in size. Now compare that to the 16K total of our two SWF files (360 x 459 pixels). That’s right, our fully interactive Flash content with graphics, fonts and animation was half the size of a JPEG!

Anyone still want to argue that Flash can’t produce compact content?

Last week saw a series of free live webinars presented by Adobe technology experts showing users how to create RIAs using the Flash platform. If you missed out or simply want to cover the material again then fear not as you can find links to each session below.

• Rapidly build, deploy, and maintain Internet apps with ColdFusion
• Bringing web applications to the desktop with AIR 2
• Code once and run on multiple mobile devices
• Going multiuser with P2P in Flash Player 10.1
• Developing multiuser applications with LiveCycle services
• Connecting a web application to a J2EE back end using Flash Builder 4
• Working with Flash CS5 components in your Flash Builder 4 project
• Erasing the designer-to-developer gap: Adding interactions to your design
• Connecting your design to PHP services

If you found the links above useful then you might want to head over to Adobe Developer Connection where you can find recordings from many other events including Flash Camps to the recently held Adobe Developer Week.

With all the recent hype surrounding HTML5 it’s easy to forget how innovative the Flash platform continues to be. Flash video in particular has taken a bashing of late from the Apple camp and with Adobe so eager to defend video in Flash many seem to have forgotten that Flash can do so much more. If you don’t believe me then take a look at the excellent video below that highlights just a fraction of the great content made possible thanks to the Flash platform.

If that has whetted your appetite then pop over to Michaël Chaize’s blog where you can find links to many of the applications shown above. Some of my favourites include an excellent demonstration of face recognition, an AS3 voice recognition library and a fantastic World Construction Kit that utilises the C++ Box2D physics library, running via Adobe Alchemy.

Flash has been driving innovation on the web for years and will continue to do so.

Well Friday night was something special. The greatest minds in the Glasgow Flash community met up to discuss all things Flash related and to have a good ol’ iPhone bashing session. But wait a minute, it turns out that even Flash devs are divided by all this Flash v iPhone malarkey. Incredulously some even seem to think that Steve jobs is right to ban Flash from the iPhone! What the frak! The night nearly ended-up in fisty-cuffs I tells ya. Oh and a special guest from Finland turned up too, but let me introduce everyone first.

So who are all these brilliant individuals? Well the group was kinda split into two camps – actual Flash developers (myself, Lindsey, Jamie and Dave), and special hardcore mobile Flash Player developers (Alex, Cameron, and Dave again). You mean to say you had actual C engineers from Adobe at Glasgow Flash Meetup? Well not exactly. You see these clever dudes used to work for a company who built their own Flash player for mobile even before Macromedia released Flash Lite 1. Pretty cool huh?

To be honest, all the individuals I’ve mentioned are so good at what they do it makes me sick, but I’m gonna try and not hold it against them, and actually sing their praises a little. Let me start with Lindsey and Jamie. You see they’re both super special because unlike most people they’re pretty amazing coders and artists. What you don’t believe me? Well take a look at Lindsey’s gallery then, and this photo of an amazing painting Jamie did of a cheeseburger sitting on an Atari ST. If you take a look at the comic strips in this post you’ll realise that Jamie is a bit of a loose cannon but please don’t hold it against him.

Now onto the C engineers. Well Alex still works for the same company that produced the Flash Player and he’s also currently working on an XBox game in his spare time. I honestly think Alex must be the best C coder in the world. In fact I barely understand a word he says, mostly because I think he actually talks in C rather than English. Cameron too is a C guru who loves registering great domain names (his latest is a cracker) and dreams of stealing money from cash machines.

Finally there’s the enigma known as Dave. I could write several pages about Dave (in fact I did just that once) but this quick paragraph should suffice. Dave is an Apple fan boy and can code in almost any language. For several years he worked as a C engineer with Alex and Cameron writing a Flash player. His career took a turn for the worse when he started sniffing glue. Before Dave knew it, his life was out of control and he found himself reduced to coding in ActionScript. Even today he works full-time as an ActionScript 3 developer, but secretly dreams of the day when Steve Jobs successfully purges the planet of Flash.

It was a good night. Jamie and Lindsey had a big argument about Flash on mobile. I tried to stay impartial, as did Dave. Later on Jamie went a little crazy and started talking about killing animals or something!? The whole Flash on mobile/iPhone debate was very interesting. Jamie seemed to think that running Flash on mobile was simply impossible. Others argued that HTML5 and JavaScript on mobile wouldn’t be any faster than Flash. Personally I passionately believe that there is a place for Flash on mobile so it was good to see Lindsey fighting in my corner.

The night was made extra special by the appearance of a guest of Jamie’s who’s currently working for Nokia. I seem to remember loud music, lasers and pyrotechnics going off as he entered the room. But then again that might just be my mind playing tricks – I do like my Nokia phones. It was kinda like being in the same room as a rock star so it took me a while to pluck up the courage to talk to him. Glad I did though coz the dude had some pretty interesting things to say. For liking Nokia so much he installed a secret app on my phone. It turns any photographs you take into comic strips complete with speech bubbles. Pretty sophisticated stuff don’t you think? Sure did come in handy for this post.

Upon arrival at this year’s Developer Developer Developer event I knew I was going into the hornet’s nest. It’s not easy trying to go unnoticed at these things you know, especially when you’re the only Flash developer there amongst a crowd of several hundred soulless dot net geeks. Somehow they can just tell you’re different, as this poor Flash developer found out to her cost at last year’s DDD event.

Desperate to avoid a similar fate I enlisted the help of a few dot net peeps I work with who were also going along and who promised not to alert the others to my presence. Basically MacDog told me the best way to fit in was to go unwashed for a whole week and then make snide remarks on the day whenever anyone mentioned Adobe or Flash. He’s been following this code of conduct for several years now and it seems to be paying off for him, although he does have to keep the windows open at work to get rid of the smell.

His advice worked and if the truth be told I kinda got more into it as the day progressed, even randomly adding in some guttural barks and yelps of delight whenever anyone mentioned HTML5.

In fact first up on the day was Craig Nicol with HTML5: The Language of the Cloud? He gave a whirlwind tour of some of the new features of HTML5 including Canvas support and video playback. Of course just about everything he demonstrated had a list of caveats attached to it and the demonstrations on offer weren’t anything I hadn’t seen before, but it was a good presentation and served to highlight the many great things we can expect from HTML over the next few years.

I’m hoping to find some time to tinker with HTML5 at some point, it’s just a pity I’m going to have to go back to using JavaScript rather than ActionScript 3. I remember the dark days of ActionScript 1 and find it quite startling that web browser implementations of JavaScript have barely evolved.

By far the most entertaining presenter on the day was George Adamson. His session was billed as a fast-pace introduction to JQuery and he promised to avoid boring slides. Well George kept his promise and delivered the best introduction to JQuery you’re likely to see in under 30 minutes. For those Flash devs who don’t know, one of the many things JQuery can do is let JavaScript developers create cool programmatic animations in a very similar manner to APIs like Tweener and Greensock.

So why the heck am I telling you all this? This is a Flash blog right? Well of course it is, but the simple fact is that as HTML5 continues to standardise, many of the tasks that would normally have been done in Flash will most probably be implemented in HTML5 and JavaScript. But whereas the very mention of HTML5 or Flash seems to polarise people I say let’s embrace all these technologies. As developers we shouldn’t be picking sides, rather selecting the correct technology for the job.

As a Flash developer my skills are transferable. I know ActionScript inside out and I’ve been using tweening engines such as Tweener and Greensock for some time. Working with HTML5 video and rendering pixels to the Canvas shouldn’t be that difficult. So to everyone out there in the Flash community, embrace HTML5. Let’s flood the web with HTML5 version of the banner ads we used to do in Flash and watch as everyones browser slows to a crawl. It’ll be no time at all before everyone is banging on about how slow HTML5 is and how all it’s good for is producing banner ads. Before long they’ll come flooding back to Flash

Seriously though, I really enjoyed DDD and hope to be back next year (if they’ll have me back after this post that is ). A big thanks to all the presenters and to Glasgow Caledonian University for hosting the event.

Here’s a video I’ve been meaning to post for a few weeks now. It shows performance comparisons for Flash Player 10.1 against HTML 5 across both the Mac and the Google Nexus One. In order to perform the test a simple particle engine was written that was easily translatable between ActionScript and Canvas. The tests weren’t actually restricted to Flash and HTML 5, with versions of the particle engine also being written in HTML and SVG.

The short answer is that Flash is still king but the other technologies, in particular Canvas, were catching up. Of particular interest was Flash Player 10.1′s performance on the Google Nexus One. The HTML 5 demo on the Nexus One was managing approximately 13 frames per second while the same demo running in Flash was hitting between 26-28 frames per second. Even running in Safari on the Mac the Flash demos outperformed the same HTML 5 demos.

All very interesting but admittedly the tests are hardly the most scientific. If you’re interested then jump over to Michael Chaize’s blog where you can find out more.

Our new programmer Ian had managed to avoid using Flash since arriving at WeeWorld, but his luck ran out the other day when he was asked to work on some legacy ActionScript 2 code. I had a bad feeling he wasn’t going to enjoy it, partly because he’d just recently declared C# his new all-time favourite language, but mostly because AS2 is quite rubbish.

Sure enough, 30 minutes in he started muttering stuff under his breath and striking the keys on his keyboard just a little too hard. About an hour later he started shaking his head in disgust and became quite vocal about how backwards everything seemed. By mid-afternoon he’d become delarious and had stopped responding to instructions. Come five o’clock the poor guy looked like he’d suffered some kind of brain injury.

Thankfully he seems to be on the mend but is now insisting that he hates Flash. Maybe he’ll respond better to ActionScript 3.

So here it is: Apple’s latest technical marvel.

No wait a minute, that’s not it! Ah here it is.

Sorry my mistake, but it’s an easy one to make I suppose. After all both are quite large, touch-sensitive, and extremely shiny. Any other similarities? Oh yeah, and neither support Flash, although at least the Monolith’s creators have an excuse seeing as Flash wasn’t around a billion years ago when the Monolith was actually built.

It’s clear Apple hate Flash. It’s clear Apple really want to kill Flash. And it’s clear they have a plan. If their devices can gain enough penetration then the need for Flash will diminish as more sites ditch it to ensure a better experience across Apple’s products.

I’d asked in my previous post whether HTML5 would kill Flash. I think Apple are more of a threat to Flash than any single web standard, and I still firmly believe that Flash’s future lies in its success on mobile.