Email Updates RSS Subscribe

This blog is created and maintained by the technical team at Hook in an effort to preserve and share the insights and experience gained during the research and testing phases of our development process. Often, much of this information is lost or hidden once a project is completed. These articles aim to revisit, expand and/or review the concepts that seem worth exploring further. The site also serves as a platform for releasing tools developed internally to help streamline ad development.


Hook is a digital production company that develops interactive content for industry leading agencies and their brands. For more information visit


Digital Sheep: Air For Android Drawing Performance

Posted on January 13th, 2011 by Jake

** Please see the update at the bottom of the post **

Hello. My name is Ovisaries McWhoolington. My friends call me Ovis. I am a sheep. I am here on behalf of the group (S)heep (H)ating on (A)ll (V)ariations (E)ndangered and (D)igital. We are here today to talk about the most recent egregious overuse of cute sheep in a digital format. The aptly named AirForAndroid Sheep Drawing Test application. Its not like these fluffy clumps of digital sheep pixels are even being put to use to save the world, or stop world hunger. Nooo, they are just pushed on and off of the screen seemingly at random, being spun around, bounced about, stretched (as in The Rack), and made into ghosts! With the flick of a checkbox, they are made into floating ghostly sheep spirits. F’n translucent, undead SHEEP GHOSTS! This is all being done in the name of “performance benchmarking”. Hardly a worthy cause.

Sheep Test Main ScreenSheep Test Settings Screen

Proof of this horrific tragedy can be found in Drawing Performance Test app. Which can be downloaded for Win/Mac/Linux/Android CPU/Android GPU accelerated here:

Android GPU Mode

Android CPU Mode

Sheep Draw Test For Win/Mac/Linux Desktop (Adobe Air)

When loaded you will be greeted immediately with a plethora of falling sheep bouncing all over the screen. This is an OUTRAGE! As if to rub it in our faces, the bottom left hand corner of the app shows at how many frames per second these sheep are being abused, as well as how many frames per second the sheep are intended to be abused!

More of this atrocity can be uncovered by clicking on the “Options” button. This is where the details of the tortured are spelled out. These poor sheep can be rendered (YEAH I SAID RENDERED!) via three different methods. Blitting (copyPixels()/draw()), Vector Rasterization (contained in an sprite), and Sprite (which is a bitmap contained in a sprite). Sizes can also be varied. As you will see the sizes are all premeditated! 64 was chosen because its small but still a power of 2 (see the old mobile flash optimization page), 65×65 because its just over a power of 2, and 128 because its big and still a power of 2.

As a final plea I provide you actual source code specific to each of these torture methods:

Different draw methods used based on options

if (_settings.isScaling || _settings.isRotating)
     _mat.tx += _pt.x;
     _mat.ty += _pt.y;
     _canvas.draw(_src, _mat, _colorXForm, null, null, _settings.isSmoothing);
    if (_settings.isAlpha)
         _canvas.copyPixels(_src, _src.rect, _pt, _alphaBD, null, true);
         _canvas.copyPixels(_src, _src.rect, _pt);

Animation is done by swapping out bitmap data for the bitmap itself.

//set during init
cacheAsBitmapMatrix = new Matrix();
//checked during update
if (_settings.isAnimated)
     if (_frame == 0)
          _frame = 1;
          _bmp.bitmapData = _alt;
          _frame = 0;
          _bmp.bitmapData = _norm;
      if (_settings.isSmoothing)
           _bmp.smoothing = true;

Some things to note here are:
- That the main container is a sprite, which contains the shape from the library
- The different sizes are not scaled to size, but are separate shapes pre-scaled to the proper size, so as to not affect performance.
- CacheAsBitmap() and CacheAsBitmapMatrix() are NOT used. We wanted to test raw vector performance.
- Vector rasterization proves to be brutal on the phones, be careful of how many vector sheep you try to draw at once.

I, Ovisaries McWhoolington, stand here, on four legs, before you fine people with a plethora of evidence that points to a blatant abuse and inhuman treatment of cute digital assets. I beg of you, do the right thing…

Thank you.

Further evidence has been submitted below.

Here is a list of quick notes I jotted down during testing:
Vector Scaling doesn’t make any difference
Blitting is much faster on the Droid1 than the N1 or Evo
Seems like the blitting erase(fill rect) is a bottleneck
65×65 Didn’t make much of a difference (for any draw method)
Alpha Kills Sprites
Changing the Frame Rate didn’t seem to make a difference (GPU) (lowering to better match max)
Upping the Blit Size to 128 didn’t make much of a difference
Overlap seems to make a difference with sprites.. more so in CPU mode
Battery Usage was worst on Droid, and Best on N1
Animation on GPU is terrible, animation on CPU is slightly better

** Update January 24 2011 **
Chris over at TheoryNine had the brilliant idea of trying graphics.bitmapFill() to draw the images on screen. This method has been added to the sheep test app as the “graph” option. As it turns out, it is quite fast in CPU mode. There is virtually no hit for using animated images, and the maximum frame rates are much higher than all of the other render methods, in CPU or GPU mode. There are a few downsides however. In GPU mode using Sprites, there is no real hit from using scaling(within reason) or rotation. Where as there is a hit taken when using rotation and scaling (major hit) with bitmapFill(). The bitmapFill() method seems to be limited by how much there is to draw. For instance using the 128×128 sheep is brutal with bitmapFill() where as Sprites in GPU mode is much faster.

Tests on the Nexus One (translation only):
GPU – Sprites 40 Sheep @ 128×128 – 30fps
CPU – BitmapFill – 40 Sheep @ 64×64 – 18fps

GPU – Sprites 40 Sheep @ 64×64 – 34fps
CPU – BitmapFill – 40 Sheep @ 64×64 – 48fps

GPU – Sprites 100 Sheep @64×64 – 27fps
CPU – BitmapFill – 100 Sheep @ 64×64 – 19fps

All of the charts (remind me not to do this again, it took forever!)

T = Translation
R = Rotation
S = Scaling
A = Alpha
N = Animation
M = Smoothing



35 Responses to “Digital Sheep: Air For Android Drawing Performance”
  1. tayfun says:

    I ran the tests with an Asus Transformer. You can see the results here

    Just in case you want to put them in your post

    • Jake says:

      Thank you very much for those! I haven’t had a good chance to really study them yet, but they aren’t looking as high as I expected… Thanks again for running the tests!

      • tayfun says:

        no problem, I was very curious myself and wanted to know how it would go. Actually I’m a little disappointed by the results.
        Any chance you could share the source? I’d try putting this on an iOS device to see how those would go?

        • tayfun says:

          I think the tests should be repeated with the current AIR runtime. I just ran a few of them on my Nexus One and got way better results.
          for example:

          100 Sprites – 128*128 – GPU – TRAM – 22 fps
          100 Sprites – 64*64 – GPU – TRAM – 29 fps

          Also there is something fishy going on with the Transformer. First of all the same test (100 Sprites – 128*128 – GPU – TRAM) gets only 16 fps and second of all the graphics are all scrambled up. I posted something about that here

        • Jake says:

          That is very strange what is going on in GPU mode there… Are your textures/bitmap sizes powers of 2? I’m wondering if there is some strange interpolation going on.. Do you see the issue with the sheep test as well when using the 64x64px sheep?

          Also here is the source:

          ** It is important to note that the tests in this post were run using the AirForAndroid 2.0 and the Flex 4.0 compiler… I get the feeling that if I re-ran the tests with 2.7 and Flex 4.5, the performance would be higher. **

          You will also need to grab TweenLite to compile the code ( This was just used for the UI stuff, none of the sheep drawing stuff used it.

          please let us know what kind of numbers you get on the iDevices too if you get a chance :)

          Thanks for your contributions! I really appreciate it!

          • tayfun says:

            Hey, I’ve been doing some testing with some iOS devices, you should check out the results.

            I also tried out removing cacheAsBitmap and cahceAsBitmapMatrix for the Sprites, and this removed the issue on the Transformer I described above. This also resulted in little performance improvements, which is odd. I’m guessing this has something to do with the fact, that the Sprite is only holding a Bitmap, and therefore is already being cached on the GPU, not sure though :/

            I’m still not sure which setup to use, but looking at these examples and , I’d say using Sprites is the way to go.

  2. devu says:

    Hi Jake. I was digging around for something like this for a while. I am working on some gui framework for Android already. ( And was doing brute force generic test for all those sort of methods. Get to exactly same conclusion. Native Drawing API is the fastest method. Even with newest version of Android and AIR on Google Nexus S.

    For example 100 sheep 64×64 60/60fps! So get to conclusion is actually my Nexus S is doing so well or/and newest version of AIR. Not necessary the way how the stuff is written.

    At the moment I’ve got 240 elements on the screen performing with acceptable 27FPS. There is still a room for further improvements not mention your Alchemy libs ;)

    • Jake says:

      Hey thats awesome! For the 240 count were you referring to this sheep app or was this an air test you made, or was that with the native drawing api? I took a quick look at the GUI lib stuff (the examples you had posted), looks pretty sweet, I’ll have to play around with that as soon as I get some time. Thanks much for contributing your scores!

  3. sydd says:

    Nice article.

    Do you know how this performance compares to “normal” android apps build with the android SDK? Approximately how faster are they?

    • Jake says:

      Thanks! unfortunately I do not know, but I would imagine it depends on how you do the drawing. If you draw with openGL, or use the built in views in the JAVA sdk, or even the new renderscript in Honeycomb… If you ever find out, please let us know!

  4. Barliesque says:

    I’d be interested to see how these tests are effected when you turn off anti-aliasing by setting stage.quality = StageQuality.LOW;

    • Jake says:

      You my friend are a genius! I completely forgot about that! Short story is StageQuality.LOW made a huge difference in CPU mode, and almost no difference in GPU mode. These tests were run on my Stock N1 running Gingerbread 40 sheep, with translation and rotation:

      Default Stage Quality:
      Graph: 44fps
      Sprite: 17fps

      Graph: 7fps
      Sprite: 38fps

      Low Stage Quality:
      Graph: 57fps
      Sprite: 24fps

      Graph: 7fps
      Sprite 41fps

      With rotation off I get 60fps for 40sheep in CPU mode using the bitmapfill method on graphics objects.

      I’m out of room on the Options Screen for more options. If I get some time, I might find a way to add those in, or make a second screen.

      Again, good call!

      • Barliesque says:

        Excellent! I’d completely forgotten I posted that suggestion, so glad I came back. Now I just need to find out how to detect if GPU acceleration is available, and if not automatically set the quality to low.

        So, I was just coming back here having installed the latest update to the Android Air Player (, and discovered that Sprites now draws as fast as bitmap fills. On my Galaxy S, running Android 2.2, with Translation, Rotation and Smoothing turned on, 40 sheep 65×65, I get a rock solid 56/60

        • Jake says:

          oh thats awesome, on my Droid1 and N1 the update didn’t seem to make much of a difference unfortunately, but they are both running Gingerbread at the moment… maybe I should switch back to 2.2 and see what the effect is..
          In your test were you referring to GPU and CPU?

          • Barliesque says:

            GPU, forgot to mention that. At this point I’m kind of wondering whether it’s worthwhile targeting phones that don’t have a GPU. That’s surely a demographic that will shrink quickly, and I would think anybody with any interest in playing games on their phone will be among the first to update their gear.

          • Barliesque says:

            …just repeated the test with CPU, and found that Graph still beats Sprite by a wide margin: 20/60 versus 40/60.

  5. Jake says:

    @Matt, wow that is weird. Unfortunately I don’t have an Incredible to test this with. I guess it is possible that air is falling back to CPU mode. I was looking through the docs again, but I don’t see a way to query the rendering mode from the api. I may have missed it, but thats the only thing I can think that would determine what mode its really running in. You should see a pretty huge difference with things that would change the gpu texture data, such as blit mode.

  6. Matt says:

    I’ve downloaded your tests for both GPU and CPU and get the exact same frame rates with both. I’m testing on a Droid Incredible with Android 2.2
    Does this phone not support hardware acceleration with Air for Android???

  7. [...] with Jake from byHook and testing the graphics.drawRect() approach, we have come to an interesting intitial [...]

  8. [...] via Digital Sheep: Air For Android Drawing Performance | Hook – Labs. [...]

  9. [...] Using the Graphics object has been very successful for me but I want to say that I’m absolutely sure this is not the best solution in every scenario.  Try each of the different approaches you’ve read about and see what works for you and your game.  Another solution can be found here. [...]

  10. James Li says:

    Cool! Thank you for sharing this!

  11. [...] Using the Graphics object has been very successful for me but I want to say that I’m sure this is not the best solution in every scenario.  Try each of the different approaches you’ve read about and see what works for you and your game.  Another solution can be found here. [...]

  12. [...] A great comparison of different hardware platforms (3 different android phones), draw methods (sprite, blit, vector) , including a great summary of good practices. Great work Jake at ByHook [...]

  13. cddin says:

    that’s cool. usefull to test how air performance in my phone.

  14. [...] This post was mentioned on Twitter by Lee Brimelow, Flex User Group, Alex, David Pett, Iwo Dziechciarow and others. Iwo Dziechciarow said: AIR performance on Android [...]

  15. Kapom says:

    Woww!! Thanks,That’s helpfull for my decission

  16. Bjarne says:

    Wow! Thanks for this awesome resource.

  17. Jake says:

    You guys are very welcome!

  18. +1 to what Lee said. Thank you for sharing this.

  19. Lee Brimelow says:

    Wow incredibly helpful tests! Thanks so much for putting this together.

  20. Jake says:

    @NeoDroid, Sorry about that felix was correct, I had the wrong QR code up there for the CPU mode, you should be able to install them at the same time now.

    @felix, thanks for catching the URL issue! To answer your question, I think its very possible to make a game that runs at 30fps… I am currently working on 2 very different types of games using Air for Android. One is draw heavy (which is what spurred this demo) and one is SQLite and Memory heavy. The draw heavy one keeps up just fine really, even with touch inputs. SQLite one is a different story. But that one is no where near the optimization stage. The settings used in the data were meant to push the hardware. I’m guessing you won’t need to draw 100+ rotation, alpha, scaling, translating sheep at 30fps :) However if its frame-based animation heavy (eg. sprite sheets, timeline animation), I’m not sure. I haven’t found a fast way to do that yet. But there has to be some way.

  21. felix says:

    Great data – thanks! What is the executive summary? Is AIR on Android fast enough for a games? It seems like most of the frame rates in your results are well below 30. BTW – both the QR codes point to the GPU version.

  22. NeoDroid says:

    Great demo! BTW, what tween engine are you using in this benchmark?

    Also, would it be possible to give the APK’s unique names? Cuz, I can’t install them at the same time because they overwrite each other.

  23. [...] Air For Android Drawing Performance Tests Digital Sheep: Air For Android Drawing Performance | Hook – Labs. [...]

Leave a Reply