[android-developers] Re: Loading Bitmaps in native heap
I had the same problem when loading as ARGB_565. Use inDither to get rid of very obvious stair-stepping. I would say I could spot a 16-bit image, especially with a lot of reds, on a less red screen (Xoom and Acer Iconia Tab A500) while the Galaxy Tab 7 is a whole splotch of red. However with inDither on gets a bit hard to tell! On Jun 9, 4:50 am, webmonkey webmonke...@gmail.com wrote: That works but I don't consider 16-bit to be full-resolution, color fidelity is just as important. On Jun 8, 10:25 pm, Streets Of Boston flyingdutc...@gmail.com wrote: I guess it's playing nice to other background apps. Even a foreground app can't gobble up all the memory and starve the background apps. I figured out a way to edit 9MPixel images 16-bit (i.e. 18MByte of data). It makes you program quite carefully when using the left over 6Mbyte of memory, but it's possible. On tablets, i think that the limit has been raised to a 48MByte heap. Since the 1st gen android phones never had cameras with more than 5MPixel and 2nd gen android phones never had cameras with more than 8MPixel, it worked out for my app. But if images are side-loaded (e.g. from a sd-card or downloaded from the web), which could be larger than 5 or 9 MPixel, then my app would fail to handle these. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Loading Bitmaps in native heap
On some devices that is going to be way over budget. The 8mp example is the max case. I don't expect low-end devices to have an 8mp camera. So let me try again, about 64MB of extra space in native on a phone that has 512MB of RAM, is that reasonable? I am just trying to find a right balance here to take advantage of the memory when it is available. Also note that such memory use would be for periods where an image is loaded and edited, so it is not allocated all the time. On Jun 9, 12:30 am, Dianne Hackborn hack...@android.com wrote: On Wed, Jun 8, 2011 at 3:17 PM, webmonkey webmonke...@gmail.com wrote: No, as I said, your app will eventually be silently killed. OK, but not if you are a foreground app, wouldn't be very silent ;-) It is silent as far as you are concerned -- no warning, no way to recover, just *poof*. I am talking sane for a mobile environment, and I already mmap everything I can. Let's say an absolute max of 2 full 8mp images, so about 64MB of extra space in native, is that reasonable for a foreground app? Keeping in mind that it is the user's choice to do this (just like he would play a high performance game) On some devices that is going to be way over budget. The amount of RAM in Android devices (at least high-end ones) has been growing quickly, but there is a wide variety across them. The numbers defined in the platform have been fairly conservative to ensure good working behavior and performance across all devices. -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Loading Bitmaps in native heap
I wrote an image editor app that claims to deal with full-resolution of the images. However, there is a limit due to the 'issues' you found (limit memory). I got around it (at least, i haven't seen many stack-traces/error-logs sent my way) by doing this: - Limit the resolution. On 1st gen devices (16MB ram), up to 5MPixel 16-bit; on 2nd gen devices (24MB ram), up to 9MPixel 16-bit images. Basically, allow the images take up all but 6MByte of the available ram (16 - 6 = 10MByte for pics; 24 - 6 = 18MByte for pics). The 6MByte buffer that can be used by the rest of my app is just an example. Your app may be able to use less... - Be diligent in 'recycle()' bitmaps *asap*. - Just before allocating a brand-new large image, call System.gc(), to trigger the garbage collector. Because the raw bitmap data is loaded on the native heap and DalvikVM can't 'see' it, the garbage collection may not have been properly triggered in time. Calling System.gc() is just to make sure that it does the collection if necessary. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Loading Bitmaps in native heap
It is kind of ridiculous that you cannot just load a bitmap in full quality the size of the phone's camera capability, let alone edit it. Then you have to explain to users that you can't because you can only use 16/24/32 MB when their phones have 512MB. As open and powerful as Android is, I never understood why this is so limited. On Jun 8, 9:35 pm, Dianne Hackborn hack...@android.com wrote: Note that just because heap limits aren't imposed on the native heap like they are on the Java heap doesn't mean that there aren't limits. The failure cases are just more difficult -- not allowing stuff to work in the background when it should to your application just silently being killed. You *can* push the limit somewhat from the native heap, but there aren't many good ways to tell how much on any particular device. A general safe rule of thumb is to keep your native allocations below the java heap limit as well independent of what is allocated in Java. Also keep in mind that as of 3.0 there is an API to extend the Java heap to a larger safe limit for specific large apps that need it, and find out what that limit is:http://developer.android.com/reference/android/app/ActivityManager.ht...() On Wed, Jun 8, 2011 at 10:17 AM, Erik R ejwrobert...@gmail.com wrote: I'm working on a simple image manipulation app that requires opening bitmaps at full resolution, which of course results in OutOfMemory issues. I know that the short answer is to simply use less memory via BitmapFactory's inSampleSize Option to downsample the bitmap, but for this app I really would like to retain the full resolution for editing. One solution I have been investigating is loading the bitmap entirely on the native heap, after learning that the memory limitation is only imposed within the Dalvik VM heap. A look into the Android source code revealed that this is already the case... BitmapFactory uses native methods to load a bitmap on the native heap, while maintaining a reference to it on the VM heap. The issue then is that it appears the native memory used by the bitmap is actually counted against the available VM memory, when it really isn't there. A look into the stock Camera and Gallery apps' source revealed that they get around this by using an additional BitmapFactory Option, inNativeAlloc. I was able to find this field in the Java code for BitmapFactory: 196 * Normally bitmap allocations count against the dalvik heap, which 197 * means they help trigger GCs when a lot have been allocated. However, 198 * in rare cases, the caller may want to allocate the bitmap outside of 199 * that heap. To request that, set inNativeAlloc to true. In these 200 * rare instances, it is solely up to the caller to ensure that OOM is 201 * managed explicitly by calling bitmap.recycle() as soon as such a 202 * bitmap is no longer needed. 203 * 204 * @hide pending API council approval 205 */ 206 public boolean inNativeAlloc; Are there any plans to unhide this field anytime soon? -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Loading Bitmaps in native heap
How does the native heap actually tell you, will malloc return NULL if it cannot reserve enough space? And if you are a foreground app, you won't get in trouble will you (unless you use insane amounts of it) I can understand that a background app should not use more native memory than the limit. On Jun 8, 9:35 pm, Dianne Hackborn hack...@android.com wrote: Note that just because heap limits aren't imposed on the native heap like they are on the Java heap doesn't mean that there aren't limits. The failure cases are just more difficult -- not allowing stuff to work in the background when it should to your application just silently being killed. You *can* push the limit somewhat from the native heap, but there aren't many good ways to tell how much on any particular device. A general safe rule of thumb is to keep your native allocations below the java heap limit as well independent of what is allocated in Java. Also keep in mind that as of 3.0 there is an API to extend the Java heap to a larger safe limit for specific large apps that need it, and find out what that limit is:http://developer.android.com/reference/android/app/ActivityManager.ht...() On Wed, Jun 8, 2011 at 10:17 AM, Erik R ejwrobert...@gmail.com wrote: I'm working on a simple image manipulation app that requires opening bitmaps at full resolution, which of course results in OutOfMemory issues. I know that the short answer is to simply use less memory via BitmapFactory's inSampleSize Option to downsample the bitmap, but for this app I really would like to retain the full resolution for editing. One solution I have been investigating is loading the bitmap entirely on the native heap, after learning that the memory limitation is only imposed within the Dalvik VM heap. A look into the Android source code revealed that this is already the case... BitmapFactory uses native methods to load a bitmap on the native heap, while maintaining a reference to it on the VM heap. The issue then is that it appears the native memory used by the bitmap is actually counted against the available VM memory, when it really isn't there. A look into the stock Camera and Gallery apps' source revealed that they get around this by using an additional BitmapFactory Option, inNativeAlloc. I was able to find this field in the Java code for BitmapFactory: 196 * Normally bitmap allocations count against the dalvik heap, which 197 * means they help trigger GCs when a lot have been allocated. However, 198 * in rare cases, the caller may want to allocate the bitmap outside of 199 * that heap. To request that, set inNativeAlloc to true. In these 200 * rare instances, it is solely up to the caller to ensure that OOM is 201 * managed explicitly by calling bitmap.recycle() as soon as such a 202 * bitmap is no longer needed. 203 * 204 * @hide pending API council approval 205 */ 206 public boolean inNativeAlloc; Are there any plans to unhide this field anytime soon? -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Loading Bitmaps in native heap
I guess it's playing nice to other background apps. Even a foreground app can't gobble up all the memory and starve the background apps. I figured out a way to edit 9MPixel images 16-bit (i.e. 18MByte of data). It makes you program quite carefully when using the left over 6Mbyte of memory, but it's possible. On tablets, i think that the limit has been raised to a 48MByte heap. Since the 1st gen android phones never had cameras with more than 5MPixel and 2nd gen android phones never had cameras with more than 8MPixel, it worked out for my app. But if images are side-loaded (e.g. from a sd-card or downloaded from the web), which could be larger than 5 or 9 MPixel, then my app would fail to handle these. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Loading Bitmaps in native heap
That works but I don't consider 16-bit to be full-resolution, color fidelity is just as important. On Jun 8, 10:25 pm, Streets Of Boston flyingdutc...@gmail.com wrote: I guess it's playing nice to other background apps. Even a foreground app can't gobble up all the memory and starve the background apps. I figured out a way to edit 9MPixel images 16-bit (i.e. 18MByte of data). It makes you program quite carefully when using the left over 6Mbyte of memory, but it's possible. On tablets, i think that the limit has been raised to a 48MByte heap. Since the 1st gen android phones never had cameras with more than 5MPixel and 2nd gen android phones never had cameras with more than 8MPixel, it worked out for my app. But if images are side-loaded (e.g. from a sd-card or downloaded from the web), which could be larger than 5 or 9 MPixel, then my app would fail to handle these. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Loading Bitmaps in native heap
Yeah, but it'll do. :-) The quality of the cameras on phones and tablets is not that great anyway. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Loading Bitmaps in native heap
On Wed, Jun 8, 2011 at 1:15 PM, webmonkey webmonke...@gmail.com wrote: How does the native heap actually tell you, will malloc return NULL if it cannot reserve enough space? No, as I said, your app will eventually be silently killed. And if you are a foreground app, you won't get in trouble will you (unless you use insane amounts of it) I can understand that a background app should not use more native memory than the limit. Pretty universally people coming from a desktop environment have a very different definition of reasonable amount of memory than is actually sane for a mobile environment. -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Loading Bitmaps in native heap
No, as I said, your app will eventually be silently killed. OK, but not if you are a foreground app, wouldn't be very silent ;-) Pretty universally people coming from a desktop environment have a very different definition of reasonable amount of memory than is actually sane for a mobile environment. I am talking sane for a mobile environment, and I already mmap everything I can. Let's say an absolute max of 2 full 8mp images, so about 64MB of extra space in native, is that reasonable for a foreground app? Keeping in mind that it is the user's choice to do this (just like he would play a high performance game) On Jun 8, 11:56 pm, Dianne Hackborn hack...@android.com wrote: On Wed, Jun 8, 2011 at 1:15 PM, webmonkey webmonke...@gmail.com wrote: How does the native heap actually tell you, will malloc return NULL if it cannot reserve enough space? No, as I said, your app will eventually be silently killed. And if you are a foreground app, you won't get in trouble will you (unless you use insane amounts of it) I can understand that a background app should not use more native memory than the limit. Pretty universally people coming from a desktop environment have a very different definition of reasonable amount of memory than is actually sane for a mobile environment. -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Loading Bitmaps in native heap
On Wed, Jun 8, 2011 at 3:17 PM, webmonkey webmonke...@gmail.com wrote: No, as I said, your app will eventually be silently killed. OK, but not if you are a foreground app, wouldn't be very silent ;-) It is silent as far as you are concerned -- no warning, no way to recover, just *poof*. I am talking sane for a mobile environment, and I already mmap everything I can. Let's say an absolute max of 2 full 8mp images, so about 64MB of extra space in native, is that reasonable for a foreground app? Keeping in mind that it is the user's choice to do this (just like he would play a high performance game) On some devices that is going to be way over budget. The amount of RAM in Android devices (at least high-end ones) has been growing quickly, but there is a wide variety across them. The numbers defined in the platform have been fairly conservative to ensure good working behavior and performance across all devices. -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
