Bitmap allocations always count towards your heap limit. Until Android 3.0, Bitmaps were allocated on the native heap but counted against your maximum Dalvik heap. Starting with Android 3.0, Bitmaps are allocated directly on the native heap.
On Mon, Jul 9, 2012 at 8:26 AM, Latimerius <[email protected]>wrote: > On Mon, Jul 9, 2012 at 4:53 PM, Nobu Games <[email protected]> > wrote: > > Bitmap behaves like that because it allocates memory on the native heap > for > > storing its bitmap data, meaning: it cannot use your Java int array and > must > > make a copy instead. > > One thing though that puzzles me about this is, there have been > discussions indicating that the native Bitmap memory doesn't count > towards an application's heap limit (I think someone from Google > mentioned it too at last year's I/O?). However, I'm still getting > OOM, and I'm pretty sure it my app's heap limit and not the lack of > RAM in the device that I'm having trouble with (the device is HTC > Desire with pretty much nothing else running on it so there should be > plenty of RAM available to the OS). > > I wouldn't mind the copy if it didn't contribute to my app's heap size... > > > For getting around that problem you should reconsider > > what you are doing. Try to break your big (memory) problem into several > > smaller sub-problems. > > I tried to approach it like that but the ultimate goal is a .png > stored on internal/external storage. It's mainly the > encoding-into-PNG step that I don't know how to handle in a piecemeal > fashion. I'm no PNG expert but I think that in order to produce a > .png file, all image data that are supposed to go into it need to be > in-core at the same time. > > > I don't know where your pixel int array originally > > comes from, but at some point you must have it either loaded from > somewhere > > or constructed. > > It's read in from a GL ES off-screen rendering surface. > > > You could instead operate directly on an already allocated Bitmap object > and > > modify its pixel data instead of having you int array as a step in > between. > > That's the only way I see at this point to achieve the goal at all - > I'd *love* to avoid this though as we're discussing image resolutions > like 2400x1440 here - filling each of those pixels by calling > setPixel() on it is going to take forever (and that adds to the fact > that off-screen rendering in ES 1.1 doesn't seem to be fast by > itself). > > That's why I wanted an int[], so that I can do bulk blits. > > > So if you are loading your int array from a file for example, just apply > > that data directly to the Bitmap. > > As an ugly work-around, I considered taking my int[], writing it out > to a file and releasing its memory. Then use one of the > decodeBitmap() functions to turn the file into a Bitmap. Not sure > though if decodeBitmap() handles "raw" pixel data, or if it insists on > a PNG, JPEG or similar. > > Thanks for your reply! > > -- > 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 > -- Romain Guy Android framework engineer [email protected] -- 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
