1 Reply Latest reply on Aug 8, 2006 7:22 PM by jpwrunyan

    BitmapData & ByteArray Compilations

    madgett
      We all understand that a bitmap is composed of a specific amount of pixels. What I tried to do to test out the new AS 3.0 compiler was get all the pixel data of a bitmap (125x125). That's a total of 15625 pixels. Instead of loading the bitmap in externally I looped through all the pixel data and printed it out:

      var byteArr:ByteArray = new ByteArray();
      byteArr.writeUnsignedInt (0xBB9A91);
      byteArr.writeUnsignedInt (0xBB4A32);
      ...etc (15625 lines)
      // create the bitmap dynamically
      var rect:Rectangle = new Rectangle(0,0,125,125);
      var bitmapData:BitmapData = new BitmapData(125,125, false);
      bitmapData.setPixels(rect, byteArr);
      var bitmap:Bitmap = new Bitmap(bitmapData);
      // assuming this class extends flash.display.Sprite
      addChild(bitmap);

      Now I understand that the original .as file will be large (about 500kb). However, if you compile this into a .swf the file size is about 65kb. That is more than the original .jpg image at 100% quality, which is 31kb.

      Shouldn't the .swf store the final bitmap representation in the byte array which sould be less than 2kb? I don't understand where all this overhead is needed. I understand that it's over 15000lines of code, but at compile time all that code should be interpreted as a simple bitmap data object.

      Thoughts?
        • 1. Re: BitmapData & ByteArray Compilations
          jpwrunyan Level 1
          I think this looks like a case where the algorithm cannot be less than the data it represents (I forget what that is called in theory). Unless you have a loop and can recycle the 3 byte data, the the file will be at least as big as the image and then more so on top of that because you aren't just storing 15625 lines of 3 bytes, you are storing that PLUS instructions telling flash player what to do with those bytes. Flash wouldn't know that the end result is a bitmap and therefore you can't expect anything better as far as compression or performance (I'm assuming).
          I guess the reasoning is that if you wanted the above code to be interpretted as a bitmap at compile time, flash assumes you would have given it a bitmap. Since it is not a bitmap but instructions for making a bitmap, then flash assumes, for whatever crazy reason, that you want it to build the bitmap from scratch and so wastes resources to go to that effort.