Jump to content
Search Community

Can someone from GreenSock please clarify [BLITMASK]

Applauz test
Moderator Tag

Recommended Posts

Can someone please clarify for me what the possible reasoning would be when using BlitMask I would see better performance during the tween when bitmapmode is set to FALSE.

 

I know it goes against the whole purpose of BlitMasking... but I need to target what the problem is.

 

This is while running on an iPad at 60 fps

 

rendermode is GPU

 

 

I'm tweening in a blitmasked area of 1024 x 706

 

the movie clip I'm tweening is a horizontal strip of 29 movieclips that are added to a movie clip that is the movie clip being tweened. This makes the movie clip being tweened be approx 25,000 px wide. I thought the whole point of BlitMask would be to only worry about what's in the blitmasked area.

 

 

When bitmapmmode = false.. the tweens are perfect for the first 4 tweens ( swipes ) .. then all of a sudden it gets choppy. Not delay being added to the stage either.

 

When bitmapmode = true .. it takes 3 seconds for my movie clip to even appear on the stage... once it does appear the swiping is very laggy and after 3 swipes the app crashes completely.

 

 

Does anyone have any idea why this is happening ?

 

When I run it on the desktop there is absolutely no difference between bitmapmode true or false.. both perform great. I assume because the desktop has a lot more RAM to work with.

 

 

The weird thing is I have another area in my app where I have another large image that needs to be tweened. This one is a history timeline.. I am using blitmask and throwprops with this one. The strange thing is with this one .. bitmapmode being TRUE makes it very laggy. bitmapmode FALSE it performs flawlessly... so is there something in throw props thats helping this scenario ???

Link to comment
Share on other sites

There must be something funky going on in your project if you're getting much better performance with bitmapMode false (assuming you're just tweening x/y values and not scaling or rotating which would force a recapture of the pixels and hurt performance). It's virtually impossible to know for sure what the problem is without seeing a very simple example FLA that we can publish on our end. I really wish I had an easy answer for you, but I can assure you that BlitMask has the potential to deliver huge performance gains for scrolling large assets.

Link to comment
Share on other sites

Got the [huge] file :) It did nothing. Zero animation. No dragging. Just a black background and green square. Over 100 assets in the library, many of which have ActionScript. Can you please provide something more concise and functional? :)

 

And no, I don't have a way to test something on the iPad right now. That doesn't mean I can't identify problems in the code, though. I'd be happy to take a peek at a more functional, concise example FLA.

Link to comment
Share on other sites

I altered the first level nab so you didn't have to worry about it. Click on the green square and the section in question will animate in.

 

The only movie clip you need to look at is allChapterSwiper_mc thats where the code for the tweening is.

 

AllChapterSwiper_mc basically loads a library item movie clip called allChapters_mc and handles how it is swiped, etc.

 

inside of allChapters_mc is only some addChilds that add the movieclips to the stage inside of allChapters_mc.

 

Like I said .. if you run this on your desktop you are going to say it runs perfectly fine. The problem is when it's run on iOS.

Link to comment
Share on other sites

In order to properly diagnose this, here's what I'll need from you:

 

1) A stripped-down version of the FLA that has only the essential code to demonstrate it working with bitmapMode = true (albeit with worse performance). The version you set has everything set up for bitmapMode = false but you said the problem is when it's true.

 

2) An identical file, but with it working with bitmapMode = false.

 

(so that I can compare what you're doing)

 

I noticed a few things in the file you already provided:

 

1) The target of your BlitMask is NOT ready when you're creating the BlitMask. The getBounds() width and height are 0. You should definitely be creating your BlitMask when (or after) your asset is ready.

 

2) You've got your MouseEvent listeners set up on the target rather than the BlitMask. They won't work properly when bitmapMode is true because that forces the target's "visible" property to false, thus no MouseEvents will be sensed/dispatched.

 

I hope that helps at least a little.

Link to comment
Share on other sites

Rather than me sending you FLA's .. its only a few lines of code you need to change to see what I'm seeing.

 

Inside of movie clip allChapterSwiper_mc

 

Uncomment line 48 //TweenLite.delayedCall(0.1, blitMask.update, [null, true]);

 

Change line 52 to blitMask.bitmapMode = true;

 

 

 

This will show you the performance hit when bitmapMode is true

Link to comment
Share on other sites

I see one problem for sure: you only have bitmapMode = true on the very first drag/flick. Then you're calling disableBitmapMode() on the BlitMask at the end of the tween and you never re-enable it. This is particularly problematic when scrolling/dragging. This explains the performance hit you saw - you've completely negated the benefits of BlitMask during the interactive scrolling because bitmapMode is false at that point (except the first time). Flash is being forced to render all of the DisplayObject's pixels on every frame, plus update the BlitMask (because you're calling update() inside your ENTER_FRAME handler).

 

See what I mean?

 

I'd definitely recommend at least adding this line to your MOUSE_DOWN handler:

 

blitMask.bitmapMode = true;

 

Does that improve performance for you?

Link to comment
Share on other sites

Seriously? Are you 100% positive that you didn't miss something and bitmapMode is still false during the dragging? Please put some conditional logic inside your ENTER_FRAME handler to verify. Like

 

if (blitMask.bitmapMode == false || allChapters_mc.visible) {
trace("PROBLEM!");
}

Link to comment
Share on other sites

FYI, I tested your file's redraw regions with and without BlitMask and as expected, without BlitMask the redraw regions are huge (the entire size of your allChapters_mc on every frame) whereas with BlitMask, the redraw regions are only as big as the BlitMask (the visible area on the screen). This results in a lot less work for Flash's rendering engine. I have no idea how or why you'd be seeing WORSE performance with BlitMask on the iPad, but my best guess would be that either there's something else causing problems in your file (I don't have time to dig through the hundreds of assets and lines of code) or there's some sort of memory ceiling you're running into on the iPad.

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