Skip navigation
Currently Being Moderated

Ipad slowdown

Apr 4, 2012 8:15 PM

Tags: #memory #scrolling #flash #as3 #ipad #scroll #cacheasbitmap #removechildat #actionscript3 #loading #addchild

I'm working on an image gallery touch scrolling Ipad app and It needs to be able to scroll through a very big quantity of full screen jpg (1024x768 and possibly double size for Ipad3).

The scrolling works fine with Tweenlite, my problem is when I load and unload Movieclips containing the images, the screen freeze for ~1/2 sec cutting off the scrolling animation.

I'm using CacheAsBitmap, addChild and removeChildAt for every load and unload so I understand they all take some cpu for memory allocation etc ...


So my question is :

How can I load and unload images but still keep a smooth scrolling animation ?

Is there any way to load in the background ?


Any help would be appreciated


  • Currently Being Moderated
    Apr 6, 2012 7:21 AM   in reply to AnthonyAdb

    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.


    Here's a blitting engine and a quick demo that you can try for this but blitting itself isn't too complex.


    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.

    Mark as:
  • Currently Being Moderated
    Apr 9, 2012 11:36 AM   in reply to AnthonyAdb

    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.

    Mark as:
  • Currently Being Moderated
    Apr 11, 2012 7:02 AM   in reply to AnthonyAdb

    Two key things could help you in this situation:


    1. For image Loaders set LoaderContext#imageDecodingPolicy to ImageDecodingPolicy.ON_LOAD

    2. Reduce potention GC calls by keeping and reusing objects when possible

    Mark as:
  • Currently Being Moderated
    Apr 11, 2012 9:40 AM   in reply to AnthonyAdb

    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.

    Mark as:
  • Currently Being Moderated
    Apr 12, 2012 12:18 AM   in reply to AnthonyAdb

    Of course that deployment type is the quickest to publish but the slowest to run. 935b-8000.html

    Mark as:
  • Currently Being Moderated
    Apr 12, 2012 8:36 AM   in reply to fljot

    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.


    Here is AIR 3.2 SDK:


    Here are instructions to overlay it on Flash CS5.5: ional.html


    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.

    Mark as:
  • Currently Being Moderated
    Apr 13, 2012 6:32 AM   in reply to AnthonyAdb

    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.

    Mark as:
  • Currently Being Moderated
    May 14, 2012 7:37 AM   in reply to AnthonyAdb

    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.


    Download (has a github link there as well):


    Basics tutorials on the wiki:

    Mark as:
  • Currently Being Moderated
    May 14, 2012 9:30 AM   in reply to AnthonyAdb

    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.


    The tutorials are good. Take a look

    Mark as:

More Like This

  • Retrieving data ...

Bookmarked By (0)

Answers + Points = Status

  • 10 points awarded for Correct Answers
  • 5 points awarded for Helpful Answers
  • 10,000+ points
  • 1,001-10,000 points
  • 501-1,000 points
  • 5-500 points