Gingerbread and 32 bits windows

I recently published the slides of two Android talks Chet Haase and I gave at Devoxx in November. One slide in particular got a lot of interest from various Android web sites:

Image quality in Gingerbread

I would like to add a few things regarding this slide:

  • Applications can use 32 bits windows today (transparent windows are 32 bits for instance.)
  • Applications can force bitmaps to be loaded in 32 bits today.
  • Applications can prevent banding today (more about this in my next post.)
  • OpenGL windows remain 16 bits in Gingerbread for compatibility reasons. Some games assume this format and should not. But they do, and we don’t like breaking applications.
  • OpenGL applications can use 32 bits windows today.

To sum up, Gingerbread does not add 32 bits support to the system, it’s always been there. Gingerbread simply enables 32 bits by default in more situations than before.

13 Responses to “Gingerbread and 32 bits windows”

  1. Justin says:

    With these changes to Android’s UI, do you expect this will be faster (graphically) than previous version, or will devices incur a slightly greater performance penalty for using 32-bit graphics?

  2. Romain Guy says:

    Translucent bitmaps were already 32 bits, and had to be converted to 16 bits and blended, so it should actually be a bit faster for that case. 32 bits opaque bitmaps will draw faster on 32 bits windows that on 16 bits windows because it’s a simple mem copy. More memory bandwidth will be required if your app is drawing opaque bitmaps that used to be 16 bits but I have yet to see an application where this is an issue. And of course, if you force your bitmaps to be loaded in 16 bits, there will now be a 16 bits to 32 bits conversion. Overall there shouldn’t be much difference, but apps will use more memory.

  3. Tjerk says:

    So from this information i conclude that gingerbread will only run on high end phones, because of hardware requirements? And for compatibility reasons apps with target android 8 or earlier will still load bitmaps in 16 bit? At least from places where bitmaps are manually loaded.. And one more question, those leaked ui android changes, are they for real? Everything looks a lot more simplified, where are the nice round corners for dialogs for example… can’t wait until Thursday ;-)

  4. Romain Guy says:

    This doesn’t mean Gingerbread will run only on high end phones. This doesn’t change hardware requirements *at all*. Also, apps that target API level 8 and earlier will load bitmaps in 32 bits, they will not load bitmaps in 16 bits, unless they request it.

  5. Yahel says:

    Sadly, PowerPoint is again killing information !!

    Powerpoints without the talk are useless and 79€ just to see that one video…Well.

    Well maybe one day Google will give you the resources to make videos available as part of the Android documentation.

    GingerBread seems to be cooking in the right direction, that’s good :D

  6. Tjerk says:

    Well using 32 bits requires more memory for your app, and each app already has a memory limitation. But I suppose bitmaps are not part of that limitation? I overlooked that bitmap loading is always 32 bits.

  7. Well actually my app has now memory problems running in the Gingerbread emulator. The app draws a series of transparent images as an overlay to Google Maps. If you could help me with answering my questions I would appreciate it.
    How could I force loading these image as 16 bit?
    Would it actually make a difference in memory consumption if I do that 16 bit loading?

  8. Well, never mind, it was easier than I thought to load the bitmap as 16 bit. Here as reference for other people:

    BitmapFactory.Options bo = new BitmapFactory.Options();
    bo.inPreferredConfig = Bitmap.Config.ARGB_4444;
    Bitmap z = BitmapFactory.decode…(…, bo);

    It actually does have a smaller memory consumption, but seems to be slower.

  9. backlinks says:

    thanks for the share dude, you quite imprevise me :P

  10. Jason LeBrun says:

    Of course even with the increased heap size, not everyone is safe.

    This problem really killed us. Even with the increased heap limit, our program, which ran fine on every other platform we’ve tested (including very old, limited devices), crashes on the shiny, fast, new, resource-rich Nexus S, often with seconds. We had no idea why and eventually narrowed it down to large bitmap resources in the layout.

    The app on other devices doesn’t come close to the heap limit, but on the Nexus S, it frequently grows the heap to the crash point with just a few activity changes/orientation changes.