Jump to content
Search Community

blitMask update Crashing iPad2

Applauz test
Moderator Tag

Recommended Posts

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 ?

Link to comment
Share on other sites

That is indeed baffling - could you post sample FLAs that shows BOTH ways? One where you do a BitmapData.draw() with the same quality settings that DOESN'T crash, and another that shows the identical scenario but uses BlitMask and crashes? I'm really curious to see this.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

BlitMask could care less what type of compression the original graphics used - I think that your tests are just showing that it's a memory issue, not a BlitMask issue (I could be wrong though).

 

The compression you use just controls how the data gets smashed into the swf, but for playback, it still needs to unpack that data and render exactly the same number of pixels. The fact that your tests are working with a more compressed version of the same file indicates (to me at least) that conserving that memory initially is what's helping get over the hump. So if you, for example, compressed the image to 90% of its size, but then offset that by using an image that's twice as big, you'd still get the crash.

 

Like I said, the thing that would really help prove if it's a BlitMask issue or not is to provide what I asked for in my last response -

could you post sample FLAs that shows BOTH ways? One where you do a BitmapData.draw() with the same quality settings that DOESN'T crash, and another that shows the identical scenario but uses BlitMask and crashes? I'm really curious to see this.
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

I have no idea about a specific IPA file size limit imposed by Apple or Adobe, no, but it would make sense to me that image compression would have a memory effect even if the images aren't on the stage at that particular moment because they're part of the file that gets read into memory initially. For example, if you open a Word document (.doc) on your computer, it reads the whole file into RAM up front, even the pages that aren't on the screen initially. It isn't as though it only reads page 1 and leaves the rest on the hard drive. If it took that approach, things would be very sluggish as you scroll and the other pages are needed. Same with Flash. The only exception I know to this rule has to do with specific types of video files because they're so massive and random access works better (like NetStreams).

 

So the whole file gets loaded up front including the compressed images, but Flash is smart enough to not decompress and render specific assets until they're needed (for the most part). But the compressed versions are still in memory (RAM).

 

Does that help clarify things a bit?

Link to comment
Share on other sites

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...... :(

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...