You could use Stage3D for mobile in AIR3.2 with Starling and improve your performance a huge amount. It means learning a lot but it will be worth it. Plus just moving images like a gallery is a trivial task for Starling.

Otherwise, prior to Stage3D in AIR 3.2, to really make it as smooth as possible you're going to have to opt for a blitting technique. In a nutshell, you have a single bitmapdata that you draw the images into. Sounds complex but the performance is very good. However this technique relies 100% on the CPU which is nowhere near as fast as using Stage3D and Starling with the GPU. So you can have a Vector of sprites containing the images in your gallery and as the user moves their finger you simply keep running the copyPixels() method to draw the images into the bitmapdata.

The bottom line is the display list works great on computers but devices are absolutely not computers. They're a mere fraction of the speed of a modern computer. So while the gallery will work silky smooth using a computer, it can perform intolerably slow on devices. You need to use techniques that maximize performance rather than try to use the standard display list or (far worse) the timeline for animation.

BTW cacheAsBitmap can hurt you because devices have very little memory. Not only do they have low memory but the amount your app is allowed to use is very small. I probably wouldn't cacheAsBitmap those images. On a desktop computer I absolutely would, but not on a device.

I'd make 2 recommendations. First, let me say I've never used greensock's blitmask. I do my own blitting just copyPixels()ing from images in memory onto my bitmapdata. It's a pretty straigth forward technique.

For one, I find MOUSE_MOVE is a very sporadic and loud event. It fires off TONS of times and the firing is very erratic. What I do is start the MOUSE_DOWN. Once that handler fires I remember where my mouse is (stage position) and I just keep track of a single integer. I subtract from it if the user moves their finger left or add to it if they go right. I then use the integer to determine what pixels I need to copy and from what images (which are loaded in memory in a vector). To keep the app feeling a bit more responsive I use Event.ENTER_FRAME and sample the position rather than MOUSE_MOVE. I find it's a lot smoother.

Second, often a persons finger can go off the object it started on. You should consider listening for MOUSE_UP on the stage itself so you guarantee your success at capturing that event. Otherwise you might get some odd behavior if the MOUSE_MOVE event is allowed to continuously fire like crazy.

You'll have to experiment with disableBitmapMode(), I'm not sure what will run better.

Just remember to do as little as humanly possible in whatever event handler handles moving your tween. If you have to crunch a lot of math you'll kill your frameRate.

Should I be loading those images with a Loader instead, will that improve the performance ?

No, I thought you load them in runtime. Strange though in general. I wrote an app several monthes ago with the functionality quite similar to MinimalFolio (scrolling is done via scrollRect) — was running smoothly with AIR 3 on the first iPad (it was more then 3 images). So you're doing something wrong =) Check your app descriptor (gpu/cpu) and packaging target mode.

Oh geez, you're using CS5? You don't know what you're missing in CS5.5..

I would honestly say Flash Builder is the best path forward if you REALLY want performance but being you're probably unwilling to learn a whole new paradigm then download the trial version of CS5.5 and output your project using AIR for iOS. The output proceedure is just about the same as CS5 so there won't be any learning curve. However. The performance will be MUCH better.

Also if you take Flash CS5.5 and overlay AIR3.2 (latest version) you will also see a noticable performance bump on that.

I know it's a lot of work just to test something but I never made anything in Flash CS5 that didn't immediately make me upgrade. You'll be amazed at the performance difference using the same code.

Note: I'm only suggesting using the trials. Be warned that the CS6 suite is probably pretty close to being released. It'd be worth waiting for CS5 rather than buying CS5.5 right now. It's pegged for Juneish.

Perfect! Grab the CS5.5 trial and test your product but be sure to overlay AIR3.2 before you do it. Follow the instructions I linked you to. CS5 is only capable of producing iOS apps and it does not embed the AIR runtime. Now you'll be running the latest version of AIR runtime which itself should give you a noticable boost. It also opens up the latest AIR framework and AIR for Android and Blackberry as well which CS5 didn't have when I used it.

Downloading a trial costs you nothing. If it works, buy it. At least you know CS6 will be free for you. Good link on that offer, I wondered where that cutoff was.

Note: If you have Master Suite you obviously get Flash Pro, Flash Catalyst and Flash Builder all together. If you REALLY want the best performance with the best debugger (with profiling) with serious ease of use (eventually) in Spark/Flex, Flash Builder is what you want.

I finally got my CS5.5 last week and tested the same AS3 code using AIR3.2 and adt, the result is pretty decent on IPad 1 and 3, MUCH better than with CS5 which was very laggy, but not ultra smooth :-P

Would it achievable to get the same scrolling smoothness as the original Ipad photo app or is that impossible ?

Glad you got it to work! CS5 was simply the issue. You can use adt and AIR3.2 with CS5 but it's such a pain in the neck it's worth the money over wasted time to simply upgrade. And at the same time if you upgraded you get CS6 free. Even though CS6 is acting extremely poorly (as you can see people complaining all over) so I myself would avoid using it, even if you have it, until they fix some rampant issues.

Aside that, manual blitting is how I'd handle your situation with a Vector continuously being loaded/unloaded with the next/prev photo and simply slide them in using ENTER_FRAME blitting. It seems like you're doing that now. And this is the easy way of doing things so glad you got that working! On iPad1 I find it to be 'tolerable' but on iPad2 and up it's very smooth.

If you really want it silky smooth, you should consult using Stage3D. Blitting uses the CPU whereas Stage3D is all GPU. Use the Starling2D framework which you should find extremely simple and you can achieve near iOS native smoothness pretty easily.

Do you mean adt is only useful with CS5 ? no need to use it with CS5.5 + ? I have to say I didn't see much of a difference using it with CS5.5, not sure whats the difference with the built in flash publishing to AIR 3.2

I'm actually not using any blitting atm, my previous blitmask test didnt go so well , so I'll see how it goes with my 50+ images with dynamic loading/unloading and plan from there.

I was about to install CS6 to have a try but now I'll just wait for some fix I guess ... I hope they can patch things soon

This small catalogue I'm working on is very very simple so I'm hopping I can complete it using my limited knowledge of AS3

CS5.5 uses ADT to export for you so no, you don't need to use adt. Just use the publish menu. I 'read' that CS5 users can use adt to compile for them so I mentioned that. Only if you use native extensions will you need to use adt to compile with CS5.5. In CS6 I read they support native extensions but with all the issues I see all over the forums I'm avoid that like a pothole.

Starling2D is a great framework and for your simple needs should be ideal. It will give your performance a considerable bump. Just note that they try to make it similar to using the display list, but Stage3D and GPU programming is a whole different world. You will need to learn how to use it. Only limited flash knowledge transfers.

Do note Stage3D is below the display list in flash. Any content you add to flash's normal non-3d display list will appear over it. So if you have a background of any type you will need to put that background in Stage3D instead or you will cover it up completely and see nothing.