Jump to content
Search Community

Detect when blitmask has finished capturing bitmap ?

Applauz test
Moderator Tag

Recommended Posts

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.

Link to comment
Share on other sites

BlitMask's update() isn't a multithreaded or asynchronous routine - it just runs immediately just like Math.random() or any function you write. So there's no need to get some sort of notification or event when it's done. Literally the next line of ActionScript won't run until it's done. For example:

 

myBlitMask.update(null, true);
myFunction(); //doesn't run until the previous line finishes.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

I wonder if we're talking about different things here - the BlitMask.update() will run (and finish running) before the next line gets executed, BUT that doesn't mean that Flash has rendered everything to to screen yet. That's a different routine that is up to Flash (not BlitMask) and it's just like any other code in Flash - like if you change a MovieClip's "x" or "y" value, it happens immediately but the screen may not accurately render that for a few milliseconds.

 

If you want to wait until the pixels are fully rendered to the screen, you can wait until the next ENTER_FRAME event gets dispatched by the stage. Does that help?

 

To summarize, ActionScript execution and screen updates are two completely separate things. If you were to do the BlitMask.update() and immediately (on the next line of code) check for particular pixel values in its BitmapData, you'd see that it did indeed reflect the updated values even though the screen may not show them yet because the frame hasn't fully rendered (it can only do that after ALL of the ActionScript on that frame has been executed and Flash's graphics rendering routine has run).

Link to comment
Share on other sites

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 ?

Link to comment
Share on other sites

Yep, that's quite a dilemma that doesn't have an easy solution. You're asking a LOT out of Flash/AIR. The only thing I can think of that might help a little bit (but it may not be worth the trade off) is to manually capture the big BitmapData in chunks, spread across several frames just so that the performance hit doesn't happen all at once. Like instead of one huge capture, you split it into 10 chunks that get captured once every 5 frames, so that they're done in a few seconds and Flash has a brief breather inbetween. But ultimately that still slows things down and the aggregate total hit is probably the same if not a little bit worse. You're just spreading out the pain a bit.

 

If you go that course, you can't really use BlitMask though. You'd have to manually replicate its functionality which wouldn't be a trivial task.

 

The other option is to double-up the pixels (reduce the resolution). Like put your BlitMask inside another container; you'd make the target with half the amount of pixels so that BlitMask only has to do half the amount of work initially, and you set the scaleX/scaleY of the container to 2. Of course things wouldn't look as sharp that way.

 

Good luck!

Link to comment
Share on other sites

As far as capturing various pieces across a few frames, you'd just use an ENTER_FRAME handler and use BitmapData.draw() to capture the first x pixels, then wait 5 frames and capture the next x pixels, and so on (rinse and repeat) until you have captured all the pixels in your target. You'd record them into a new BitmapData.

 

Keep in mind the other part of what I said:

If you go that course, you can't really use BlitMask though. You'd have to manually replicate its functionality which wouldn't be a trivial task.

 

I wish I could explain how to replicate BlitMask's functionality in a brief way, but I can't. It's rather complex under the hood. Feel free to study the source though.

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