Applauz

perfect.. I was able to adapt for my needs. Thanks!

Very close but not quite what I was talking about..... In your example .. the movie clip follows along the path of the line. I'm talking more about making a graph, the line connects to each movie clip... when the Y value of any of the movie clips change.. the line always stays connected to them. Hard to explain verbally... Take a look at http://www.chartjs.org .. The example under "Simple and Flexible" is exactly what I want to achieve.

I think it would be fine if it would capture it even in 2 parts (2 frames) ... can you elaborate on this idea ?

Thanks.. this helps a lot! I'm just running out of ideas to try with this.... I hate Apple for introducing these retina screens Is there anything you can think of to combat this issue I am having? I basically have a strip of movie clips that I am dynamically creating into a strip of joined movie clips ... these are high quality images.. total width of this created interface is approx 25,000 pixels. There is interactive elements inside each of the tiled movie clips. When the blitMask captures the bitmapData.. its is a HUGE CPU hog to do it because its 25,000 pixels of information. I tried only creating tiles as I needed them .. ( always keeping 1 to the left of the visible window and 1 to the right.. so that there was only 3 tiles ever active at a given time ) .. This didn't work well .. because the movie clip is using throwProps to make it swipe enabled. .. if the user swiped quickly through it .. the adding and removing of movie clips and blitMask.update calls that would happen made the swiping very choppy during the updating. So the BEST possible performance I can get right now is by just dealing with the huge CPU processing on capturing the whole movie clip in its entirety... in Xcode Instruments.. when this process runs .. the CPU hits 128% and issues some Low Memory Warnings in the interment panel. Do you have any ideas at all at how I can reduce the CPU memory hit ?

OK I did a test with your above code... and myFunction(); gets called way before the blitMask update is finished. The reDrawing of the bitmap takes long. I even tried putting a delay on the call of myFunction of 3 seconds... and it still gets called before the blitMask update is complete

So I'm at a point in my app now where I am testing memory, etc I am noticing something interesting. Any movieclip I remove from the stage and null that contains a blitMask in it.. once removed is taking exactly 13 seconds to actually clear from memory. Any movie clip without the blitMasking technique is clearing from memory in 1 to 2 seconds. Any idea why these are taking so much longer to clear ? Even if I try to force clear with System.gc(); I see the same issue.

Not really. .. I am running tools to monitor for memory leaks... When the app first opens... none of the sections of the app have been added to the stage via addChild yet. So the app is using almost nothing in regards to CPU. Once I addChild of a section .. it does what I expect and CPU usage increases. What I do not understand is why altering compression on graphical items that have not even been added to the stage yet is affecting performance. The CPU should not be seeing a hit from any elements not on the stage. ... and based on the Memory Management tools .. its not seeing a hit because when the app first opens the CPU isn't being hit at all. ... yet somehow the compression on the library items plays a role in this. Hard to explain it......

What about when it's a delayed call though ? TweenLite.delayedCall(.5, blitMask.update, [null, true]); myFunction(); // Doesn't this run before the delayedCall is fired?

Is it possible to detect the moment the blitmask has captured the bitmapData ? ie/ is it possible to use an onComplete on a delayed call ? TweenLite.delayedCall(.5, blitMask.update, [null, true]); I would like to know when the blitMask.update has completed.

I'm wondering why altering compression settings on images that haven't even been called to the stage yet affects this ? Is there a limit on the overall IPA file size that somehow plays into the available RAM ? Seems odd if that is the case ? strange.

So .... putting compression at 90% works. Still only being set to lossless makes it crash. Wish there was a way to change those settings on the fly..... is there ?

Interesting... Just for testing I changed every image asset in my library to have "photo" compression and be compressed to 20% and the crash went away. Going to try increasing the compression now and see what happens. Apparently the blitMask isn't liking the huge "lossless" png's

Unfortunately I can't send the project itself over as it's confidential right now At best I could record a video of each scenario to show you.

The only thing I don't understand is why when I use blitMask does it crash when capturing the bitmap. Yet if I just grab a snapshot of the bitmap without blitMask it doesn't crash ? ie/ using bitmapData

The strange thing about this is that on earlier AIR (2.7, 3.1, 3.2, 3.3) the problem was that iPad3 was having memory issues and iPad2 was near impossible to crash. Now running AIR 3.4 Public .. the problem has reversed. I am getting a "Received memory warning" in the XCode Instruments panel. This happens at the exact moment I use the blitMask to capture a fairly large bitmap. var blitMask:BlitMask = new BlitMask(allChapters_mc, 0, 0, 1024, 706, false); TweenLite.delayedCall(1, blitMask.update, [null, true]); The crash occurs right when this blitMask.update is called. on Android, PlayBook and iPad3 there is no problems. Any ideas around this ?