Downscaling images in Flash applications

The other day I ended up in an interesting discussion regarding how to downscale a large image in a Flash based application. What we figured out was that even though the FlashPlayer can do bilinear smoothing on scaled images automatically, this will fail when the scaling factor is more than 2 times of the source image. Hence a custom method is needed.

The simple approach (scaling down less than 2 times the size)
If the loaded image is to be scaled less than 2 times (400 -> 200) simply use the build in "smoothing" property of the Bitmap Class. This can be set directly on the Bitmap itself or via different DisplayElements such as the mx:Image in Flex. If you set this property to true the Bitmap will use bilinear scaling, achieving quite good results.

Grayscale bilinear interpolation
Now, if you need to do actual resampling of an image, in other words create a new smaller image, then you need to do this manually using the "draw()" method of the BitmapData Class. Use the bitmapData.draw() method and set the "smoothing" property to true. This will give you the same result as setting the smoothing property on an Bitmap container, however it uses less memory as only the pixels for the resulting image is stored (if you remember to dispose of the original data!).

Scaling down more than 2 times
Let's say that you have an image that is quite large and you want to create a thumbnail from it. A thumbnail is often way smaller than 2 times smaller than the original image. It would be quite nice to use the above method to just scale the image, or better resample the image with the "smoothing" property set to true. However, if you try to do this the FlashPlayer will simply fail and default back to using the "nearest neighbor" algorithm. If you try it you'll soon discover that this will give you a horrible result.

What you'll need to do in this case is to do an iterative or recursive resampling of the image at hand. In layman terms this means resampling the image several times, each time no more than 2 times downscaling factor. You could call this a multi pass resampler (actually it would be a multi-multi pass resampling as the draw() method is also multi pass). You would still use the build in "BitmapData.draw()" method to accomplish this, you only divide the work into multiple jobs. This will give you a much better result. Note that in my experience, function calls in ActionsScript 3 are quite expensive, hence a iterative approach would maybe be preferable to a recursive one.

Using PixelBender
If you have decided to go for the manual approach of resampling the picture, you can use a PixelBender shader to do the job. In this case the actual resampling will be a lot faster (as the PB language is based on C), however applying the PB shader and passing the image back and forth takes time. See the speed section..

Combining the two
So, what if you have an application and you don't know in advance the downscale factor. Well, then you'll need to use both of the approaches like so:

  1. Calculate the scale factor
  2. If the scale factor is less than 2, set "smoothing" to true on the container or do a singe pass resampling.
  3. If the scale factor is more than two, use the multi pass scaling approach. And set the "smoothing" property of the container to false (else it will be blurry).
What about speed?
Let's say that you have an image that is 1200 x 1200 pixels and you're resampling it to 200 x 200. This is a 6 times resample and will look like ass using only the "smoothing" property, but it is faster.

Let look at some hard results. In this test we see how much time is used extra compared to no "nearest neighbor" scaling (default in Bitmaps if smoothing is off).

MethodTime in ms
Smoothing property on
0 ms
Multi pass resample
9 ms
Multi pass PixelBender
32 ms
Using the smoothing property takes no extra time, because it fails and defaults back to nearest neighbor. The other two are both pretty fast, however even though the PB algorithm is way faster than the others, we see that the applying of the shader eats a lot of time, thereby making the multi pass resampler method the way to go on a large rescaling operation.

Shifting the attention - facing forward.

Innovation is the ability to see change as an opportunity - not a threat”. - Unknown

This is not where I'm going to announce to the world that I'm leaving the FlashPlayer platform behind all together. Nor is this where I'll tell you to forget everything you know, gather you wits about you and start over. No, this is where I'll tell you what I've learned, how I've learned this and why this is.

Like Borland Delphi back in the days, the Adobe FlashPlayer architecture is dying without itself being aware of it. It's not because Flash content is evil, nor because the FlashPlayer is particularity crappy. Still, many sites, like YouTube are heavily dependent on the FlashPlayer in order to display their content. This will be true for quite some time. However, at the same time, all these sites still depending on the FlashPlayer do not express enthusiasm for it, it's seen more as a necessary evil in order to get the job done while we are waiting for something better. Well, change has come to the interwebs..and it's called HTML 5.

HTML 5 is acctually a standard being developed by the World Wide Web Consortium. Like HTML 4 it's a specification used by browser vendors to integrate the support into their browsers. This by it self means that  individual browser vendors are responsible for the performance of HTML content in their browsers, effectively launching a race to be the fastest browser. This is a win for HTML 5 over Flash, seeing as Flash Player has no real competitors, because Adobe is the sole vendor. However, HTML 5 and it's companions CSS 3 and JavaScript cannot accomplish the same as the content you create using Adobe Flash, or so many people think. Actually, it can. Both 2D animations, 3D animations, advanced text layout and so on is readily available using HTML 5. So is advanced interactions. What HTML 5 does not have, that Flash do have, is an advanced authoring tool. Using HTML 5 may require more development skills, longer production time and more work to achieve the same result as using Flash authoring, today. This will change in time as HTML 5 skills grow more common amongst web-developers and the marked for great tools enlarges.


“Innovation distinguishes between a leader and a follower.” - Steve Jobs

Let's not forget the devices. The iPad, the iPhone, Android devices and the Google Chrome OS. These are the platforms of the future, the PC is not. Yeah, PCs will still be around, we as developers will still adhere like superglue to our Macs and Chrome computers. But, the normal users, aka. "most people" will not. Flash belongs to the PC era, HTML 5 is build for the touchscreen generation. This is kinda hard to see if you don't look closely, but think about it. How many iPads and iPhones does Apple sell? A lot! How many Android devices are there? A lot! Granted, Android phones do have a FlashPlayer, but have you tried it? Yes, it really sucks. And that is the most devastating blow to the FlashPlayer, the experience on future devices sucks or it simply isn't supported like on iOS devices.

Change is one of the most difficult things for humans to endure. We don't play well with it at all, but sometimes it's for the better. Remember, there is nothing wrong with plugin based technologies like FlashPlayer or Silverlight, like there was nothing wrong with the horse and carriage. But, now we drive cars, even if they can't do everything horses can do. This does not, however, mean that we hate horses, does it?

Resulting from my contemplation is an understanding that my attention will focus on the utilization of standard based technologies in the foreseeable future. I believe HTML 5 and all its companions will be the way of future web-based solutions. Flash is not dead, will perhaps never die, but if you're starting out today as a greenhorn developer, go for the future. And if you are a seasoned web-developer like myself, embrace this opportunity to learn new things, to start from "scratch".

Some great HTML 5 demos can be found here:

Do we need Flash anyway? Apple says hell no!

Unless you have been living in a box for the last couple of months or so, you're probably noticed that there's somewhat of a controversy dealing in the subject of Adobe Flash and Apple Inc.'s not so new policy to not support this widely used content type in their mobile devices.
In short, Apple cry fault on several things like CPU usage and instability, using these as the foundation for it's "no Flash content on our devices" policy. But, is it really that simple? Here's my take on this soon to be "greek tragedy".


What is Flash?
First of all, Flash is a type of media content, like images, movies and so on. Flash by itself doesn't do diddly-squat, it's just a description and a file format. In order to view Flash content you'll need an interpreter, in others words a player. What Apple is calling "the great evil" is (hopefully) the Adobe FlashPlayer, not the content type which is actually Flash.


Is Flash crashing my browser?
No! As described above, Flash all by itself can't do anything. If anything related to Flash is crashing your browser, it is the Adobe FlashPlayer. So you may ask, is the FlashPlayer the reason (most of the time) my browser is suddenly crashing? In my opinion it probably is. The Adobe FlashPlayer is quite unstable and buggy and slow. Why? Read on..


Is the FlashPlayer a "CPU hog"?
Yes it is. The Adobe FlashPlayer runs a constant loop of so called frames, driving animation, UI and so on. This will create a constant load on the CPU, because the content can change without reloading the webpage holding the Flash content. In contrast, HTML will create a heavy CPU load when initially loading the content and then it becomes static, thereby not using any (almost) CPU cycles. So, what if you where able to create the same content as you can show in the FlashPlayer in say.. HTML and JavaScript. What do you think would happen to the CPU load of that HTML page then? Of course, it would use more CPU cycles.
So, Adobes FlashPlayer is slow, no doubt about it, but this does not make Flash itself a "CPU hog" or anything like that. If Apple wants a faster FlashPlayer.. write one!

Will Flash die, what might prevent it?
Flash will die, or evolve into something else, eventually. But, it won't happen tomorrow, or the next day. Event though Apple does not support Flash in the iPhone and the iPad, almost any other device does or will support it. However, if you're a smart developer you'll use this time to widen your skill set beyond the Flash platform.

Development time and cost
The time spend creating an online application or website will in many cases be the deciding factor in a project, unless you're Google or Apple that is. Using the Flash platform compared to JavaScript/HTML solutions leaves the latter far behind in the dust when it breaks down to actual production time. This factor will no doubt change with the advent of advanced frameworks like JQuery and SproutCore. But still, anything you can do in JS and HTML, Flash can do better and faster from an time and design standpoint... today.

Dropping legacy support is the way of making a more stable player
One of the biggest problems with the Adobe FlashPlayer as I see it, is it's reluctance to get rid of old and bad ways of creating content. If Adobe where to drop support for the old player model, supporting ActionScript 2 and Flash 8 and older, I'll bet money that Flash content around the web would run faster, smoother and crash way less. If they are willing to do this I do believe Flash content might have a future, if not it will be kept alive by the need for banner ads, for a while.

Why doesn't Apple support Flash content?
Well, Steve Jobs allegedly stated that Apple wasn't supporting Flash content on the iPhone and the iPad for reasons dealing in instability, performance and generally bad user experience. If that's all, why not support Microsoft Silverlight?
Flash could be a competitor for Apple, both in the apps section of their business model and in the media consumption part (buying videos from the web (e.g. Hulu) and not the iTunes Store).
This is why, in my opinion, Apple will not support Flash content on their mobile devices. And really, if you think of it, is is such a problem? If you depend on Flash driven web content, don't buy Apple hardware. For me, being both an Apple "fan" and a Flash developer, I don't see the need for Flash content on mobile devices. No matter how you word it, the iPhone and the iPad won't give you the entire web..

Screencast # 3 - iPhone web app Twitter viewer

In this Screencast I create a really simple iPhone Web Application using DashCode, one of the tools provided trough the iPhone Developer Tools.
I'll show you how to create a simple Twitter viewer, getting started using lists and how to use value transformers in DashCode.



Download DashCode Project