Hmm. Good point. Some info I found online (forget where) suggested that Bitmap instances are fairly small since the pixel is stored externally on the native heap and the Bitmap instance only contains a reference to this externally allocated storage.
I thought this would imply that, during parceling, only the reference to this external storage would be parceled rather than its entire contents. Some other info I found talked about how, with Honeycomb, this pixel storage was allocated on the VM heap rather than in native-land. My question was trying to get at whether this change would affect how Bitmaps are parceled. Does parceling a Bitmap *really* involve string-ifying the entire contents of its pixel data? On Wednesday, September 26, 2012 10:57:08 AM UTC-5, RichardC wrote: > > Not sure where you are getting your info from can you post a reference > please? > > Bitmap.writeToParcel > http://developer.android.com/reference/android/graphics/Bitmap.html#writeToParcel(android.os.Parcel, > > int) > > Has no change notes against it and says it writes the pixels (from API > level 1) > > On Wednesday, September 26, 2012 4:22:04 PM UTC+1, Jay Howard wrote: >> >> With the changes to how bitmap data is stored that came in with Honeycomb >> affect the efficiency of parceling bitmap objects? >> >> I'm assuming the actual bitmap data wasn't ever parceled pre-Honeycomb. >> Is that accurate? If so, then my question is basically whether this >> behavior (not parceling the bitmap data) was carried forward into Honeycomb >> when the behind-the-scenes memory changes were made. >> > -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
