Lock your bitmaps!

Posted on July 12, 2007 by keith

Yesterday I posted about offscreen buffering techniques in bitmapdata drawing. And did some time tests that showed that doing a lot of drawing to an offscreen bitmap and then drawing that bitmap to your onscreen bitmap can save a significant amount of time. Guy Watson then came on and mentioned the lock() and unlock() methods of BitmapData, which, to be honest, I’d probably seen but wasn’t really aware of. Redoing the tests, locking each bitmap before drawing to it, and unlocking after drawing, showed that this brought all the tests down to the same level as the offscreen buffering example. Actual results and test code are on yesterday’s post. I just wanted to point this out in its own post in case people didn’t read all the comments. Calling lock()/unlock() is certainly a lot easier than creating a whole new bitmapdata, keeping track of it, and drawing back and forth. Thanks Guy.

This entry was posted in Flash. Bookmark the permalink.

6 Responses to Lock your bitmaps!

  1. faseer says:
    July 12, 2007 at 10:49 pm

    hi
    that’s great.
    but i don’t see the difference of use lock()/unlock() or not except improve performance.
    is that means that i should use it when handle bitmapdata?
    why adobe don’t make it default

  2. kp says:
    July 12, 2007 at 11:06 pm

    Per the language reference, “Locks an image so that any objects that reference the BitmapData object, such as Bitmap objects, are not updated when this BitmapData object changes.” So it seems it’s almost doing its own offscreen buffering – changing the model that contains the pixel data of the bitmap without updating the display. This explains why it would be quicker. Then when you are all done, unlocking it allows for a single display update.

  3. faseer says:
    July 13, 2007 at 3:58 am

    ok,thank you.

  4. ryan says:
    July 13, 2007 at 5:06 am

    Thats really cool… such a pitty so many folks may have overlooked that… I’m busy updating my pixelate class…

    Thanks

  5. Ben Stucki says:
    July 13, 2007 at 12:26 pm

    Calling lock and unlock is definitely good to know and keep in your back pocket, but locking actually has some substantial performance impact on it’s own. I’ve found that you really have to deal with it on a case by case basis to find if it’s doing you more harm than good. This is where the new profiler comes in handy.

Leave a Reply