[android-developers] Re: Bitmap memory handling with ImageView.setimage
While creating a bitmap, you should probably scale down the image
size. This is how you should do it.
BitmapFactory.Options bmpFactory = new BitmapFactory.Options();
bmpFactory.inSampleSize = 4;
Bitmap bmp = BitmapFactory.decodeFile(path, bmpFactory);
The sample size 4, will scale down the bitmap to 1/4 of the original
size. This will, in turn, reduce the size of the Bitmap object by a
factor of 4. Hope this helps.
Thanks and Regards,
Kumar Bibek
On Jun 5, 3:22 am, Nathan critter...@crittermap.com wrote:
I've read a lot of previous messages on this topic but couldn't find
universal agreement on the whole.
I can't reproduce this in house, but a customer got an
OutOfMemoryError when using an icon chooser dialog.
This dialog is much like the Grid1 example - only it's in a dialog.
The bitmap memory seems to run out after running the dialog a few
times for a customer, resulting in
java.lang.OutOfMemoryError: bitmap size exceeds VM budget
public View getView(int pos, View convertView, ViewGroup parent) {
ImageView imageView;
if (convertView == null) {
imageView = new ImageView(mContext);
//imageView.setLayoutParams(new GridView.LayoutParams(40,
40));
imageView.setAdjustViewBounds(false);
imageView.setScaleType(ImageView.ScaleType.CENTER_CROP);
imageView.setPadding(4, 4, 4, 4);
} else {
imageView = (ImageView) convertView;
}
imageView.setImageResource(idlist.get(pos).value);
imageView.setTag(idlist.get(pos).key);
return imageView;
}
Should I try to call recycle on the bitmap from an ImageView when I
reuse the view? Or would the ImageView do that anyway?
But even if I do that, that's only a small portion of the bitmaps
because most of them are seen without scrolling. The Adapter and the
GridView are both local variables and therefore shouldn't be
referenced after the dialog is dismissed.
I do believe that it should be possible to use many bitmaps in an app
- Google Maps does it, Picture Gallery does it. But maybe I need to
learn more rules. Some say you should call bitmap.recycle, some say
you shouldn't have to. Many say calling gc.collect will make it worse,
etc.
Nathan
--
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: Bitmap Memory
Well Im sorry - but this is a memory leak. Watching the core its obvious that the actual memory is being freed but when an attempt is made to use that memory the vm buffer still thinks the memory is in use. I have to say this is probably one of the worst bugs I have come across and it should be addressed rapidly. In a phone where visuals are everything to have such a HUGE problem with handling them is a real PITA. On Mar 1, 1:57 am, bra...@gmail.com peacoc...@gmail.com wrote: Best darn suggestion yet. Thankyou I was wondering if I could use that setting, but feared that perhaps I would not be able to generate new bitmaps from the original - you can - thankyou On Feb 27, 1:19 pm, Alexey Krasnoriadtsev ale...@agilefusion.com wrote: There best working approach is to only load Bounds of the image, and then use scale to load the Bitmap of the needed size. This way you never load the full-size bitmap in the memory. http://code.google.com/intl/ja/android/reference/android/graphics/Bit... get the bounds, and then use those to calculate the appropriate sample size. On Feb 26, 2:36 pm, mark.ka...@gmail.com wrote: I'm just saying there have been a number of threads on this issue, I've had out of memory problems when processing bitmaps, and so have many other developers. It looks to me like a bug IMHO. I hope this problem will be resolved at some point. On Feb 26, 2:02 pm, bra...@gmail.com peacoc...@gmail.com wrote: If that is the case then why does calling myBitmap.recycle not give me that memory back to use for the next time I go into an edit. On Feb 26, 4:59 pm, Romain Guy romain...@google.com wrote: BitmapFactory does NOT leak Bitmaps. A 2056x1536 opaque image requires 6 MB of RAM. An application has 16 MB max. Do the math. On Thu, Feb 26, 2009 at 1:50 PM, mark.ka...@gmail.com wrote: Are you using BitmapFactory? There have been a number of threads about memory leaks, or similar problems when using BitmapFactory to process bitmaps. Using Bitmap.recycle may mitigate, but not eliminate these types of problems. M On Feb 26, 11:39 am, Mattaku Betsujin mattaku.betsu...@gmail.com wrote: I think the best solution to handle very large bitmaps is to be able to decode only a small chunk of the bitmap at a time and process it. Does anyone know if the existing Android API can support this? If not, probably one solution is to write a smart decoder (in Java, so slow :-( ) that can decode a small chunk. On Thu, Feb 26, 2009 at 11:32 AM, Tomei Ningen tomei.nin...@yahoo.comwrote: You're running into memory fragmentation problems. Bitmap memory is not allocated from the Java object heap. Instead, it's allocated from the 'malloc' heap. That's why you don't see the Java heap expanding. How big is your bitmap? If you're processing JPEG files, probably it will be better to read the thumbnail directly from the JPEG file. This way you don't need to create the Bitmap at all. On Feb 26, 9:47 am, bra...@gmail.com peacoc...@gmail.com wrote: Ok I am at the end of my rope. I am doing some image processing. I have a large image file which I open and create a smaller bitmap from. At the end of processing I call recycle on everything. I null everything. I run GC manually. I then try edit another image and I get an out of VM memory error. Bitmap exceeds etc etc. I am looking at the heap and the secone edit doesnt seem to cause it to increase at all. What else can I do. Surely google cannot possibly be suggesting that we can open one large bitmap per session and thats it?- Hide quoted text - - Show quoted text - -- Romain Guy Android framework engineer romain...@android.com Note: please don't send private questions to me, as I don't have time to provide private support. All such questions should be posted on public forums, where I and others can see and answer them- Hide quoted text - - Show quoted text - --~--~-~--~~~---~--~~ 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: Bitmap Memory
I am drawing bitmaps left and right and I hit this issue where I create a bitmap in one section of my code and when I later try to draw on it using canvas, i get bitmap recycled. but I did not null if out, or call its recycle method. Description: I have a main Class that extends View that when first loads, initiates the main screen which loads/draws on bitmaps and no problem. I then added a key event that causes this screen to go away and load the next screen. The screen logic is encapsulated in a class that I already instantiated in the Main Class constructor and in my second screen its constructor is this code: staticBg = new BitmapDrawable(Bitmap.createBitmap(320, 240, Bitmap.Config.RGB_565)); staticGr = new Canvas( staticBg.getBitmap() ); at a later time, from my first screen when I push a button, i call my init() function that trys load screen two which does a draw to this bitmap and I get the following error: 03-06 08:52:56.301: ERROR/AndroidRuntime(846): java.lang.NullPointerException 03-06 08:52:56.301: ERROR/AndroidRuntime(846): at android.graphics.Canvas.throwIfRecycled(Canvas.java:890) 03-06 08:52:56.301: ERROR/AndroidRuntime(846): at android.graphics.Canvas.drawBitmap(Canvas.java:911) It is saying my bitmap is recycled BUT from what I understand that does not happened unless you explicitly call it or the garbage collector does when there are no more references to it BUT i obviously still have a reference to it. What am I doing wrong? On Mar 1, 12:57 am, bra...@gmail.com peacoc...@gmail.com wrote: Best darn suggestion yet. Thankyou I was wondering if I could use that setting, but feared that perhaps I would not be able to generate new bitmaps from the original - you can - thankyou On Feb 27, 1:19 pm, Alexey Krasnoriadtsev ale...@agilefusion.com wrote: There best working approach is to only load Bounds of the image, and then use scale to load the Bitmap of the needed size. This way you never load the full-size bitmap in the memory. http://code.google.com/intl/ja/android/reference/android/graphics/Bit... get the bounds, and then use those to calculate the appropriate sample size. On Feb 26, 2:36 pm, mark.ka...@gmail.com wrote: I'm just saying there have been a number of threads on this issue, I've had out of memory problems when processing bitmaps, and so have many other developers. It looks to me like a bug IMHO. I hope this problem will be resolved at some point. On Feb 26, 2:02 pm, bra...@gmail.com peacoc...@gmail.com wrote: If that is the case then why does calling myBitmap.recycle not give me that memory back to use for the next time I go into an edit. On Feb 26, 4:59 pm, Romain Guy romain...@google.com wrote: BitmapFactory does NOT leak Bitmaps. A 2056x1536 opaque image requires 6 MB of RAM. An application has 16 MB max. Do the math. On Thu, Feb 26, 2009 at 1:50 PM, mark.ka...@gmail.com wrote: Are you using BitmapFactory? There have been a number of threads about memory leaks, or similar problems when using BitmapFactory to process bitmaps. Using Bitmap.recycle may mitigate, but not eliminate these types of problems. M On Feb 26, 11:39 am, Mattaku Betsujin mattaku.betsu...@gmail.com wrote: I think the best solution to handle very large bitmaps is to be able to decode only a small chunk of the bitmap at a time and process it. Does anyone know if the existing Android API can support this? If not, probably one solution is to write a smart decoder (in Java, so slow :-( ) that can decode a small chunk. On Thu, Feb 26, 2009 at 11:32 AM, Tomei Ningen tomei.nin...@yahoo.comwrote: You're running into memory fragmentation problems. Bitmap memory is not allocated from the Java object heap. Instead, it's allocated from the 'malloc' heap. That's why you don't see the Java heap expanding. How big is your bitmap? If you're processing JPEG files, probably it will be better to read the thumbnail directly from the JPEG file. This way you don't need to create the Bitmap at all. On Feb 26, 9:47 am, bra...@gmail.com peacoc...@gmail.com wrote: Ok I am at the end of my rope. I am doing some image processing. I have a large image file which I open and create a smaller bitmap from. At the end of processing I call recycle on everything. I null everything. I run GC manually. I then try edit another image and I get an out of VM memory error. Bitmap exceeds etc etc. I am looking at the heap and the secone edit doesnt seem to cause it to increase at all. What else can I do. Surely google cannot possibly be suggesting that we can open one large bitmap per session and
[android-developers] Re: Bitmap Memory
There best working approach is to only load Bounds of the image, and then use scale to load the Bitmap of the needed size. This way you never load the full-size bitmap in the memory. http://code.google.com/intl/ja/android/reference/android/graphics/BitmapFactory.Options.html#inJustDecodeBounds get the bounds, and then use those to calculate the appropriate sample size. On Feb 26, 2:36 pm, mark.ka...@gmail.com wrote: I'm just saying there have been a number of threads on this issue, I've had out of memory problems when processing bitmaps, and so have many other developers. It looks to me like a bug IMHO. I hope this problem will be resolved at some point. On Feb 26, 2:02 pm, bra...@gmail.com peacoc...@gmail.com wrote: If that is the case then why does calling myBitmap.recycle not give me that memory back to use for the next time I go into an edit. On Feb 26, 4:59 pm, Romain Guy romain...@google.com wrote: BitmapFactory does NOT leak Bitmaps. A 2056x1536 opaque image requires 6 MB of RAM. An application has 16 MB max. Do the math. On Thu, Feb 26, 2009 at 1:50 PM, mark.ka...@gmail.com wrote: Are you using BitmapFactory? There have been a number of threads about memory leaks, or similar problems when using BitmapFactory to process bitmaps. Using Bitmap.recycle may mitigate, but not eliminate these types of problems. M On Feb 26, 11:39 am, Mattaku Betsujin mattaku.betsu...@gmail.com wrote: I think the best solution to handle very large bitmaps is to be able to decode only a small chunk of the bitmap at a time and process it. Does anyone know if the existing Android API can support this? If not, probably one solution is to write a smart decoder (in Java, so slow :-( ) that can decode a small chunk. On Thu, Feb 26, 2009 at 11:32 AM, Tomei Ningen tomei.nin...@yahoo.comwrote: You're running into memory fragmentation problems. Bitmap memory is not allocated from the Java object heap. Instead, it's allocated from the 'malloc' heap. That's why you don't see the Java heap expanding. How big is your bitmap? If you're processing JPEG files, probably it will be better to read the thumbnail directly from the JPEG file. This way you don't need to create the Bitmap at all. On Feb 26, 9:47 am, bra...@gmail.com peacoc...@gmail.com wrote: Ok I am at the end of my rope. I am doing some image processing. I have a large image file which I open and create a smaller bitmap from. At the end of processing I call recycle on everything. I null everything. I run GC manually. I then try edit another image and I get an out of VM memory error. Bitmap exceeds etc etc. I am looking at the heap and the secone edit doesnt seem to cause it to increase at all. What else can I do. Surely google cannot possibly be suggesting that we can open one large bitmap per session and thats it?- Hide quoted text - - Show quoted text - -- Romain Guy Android framework engineer romain...@android.com Note: please don't send private questions to me, as I don't have time to provide private support. All such questions should be posted on public forums, where I and others can see and answer them- Hide quoted text - - Show quoted text - --~--~-~--~~~---~--~~ 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: Bitmap Memory
Best darn suggestion yet. Thankyou I was wondering if I could use that setting, but feared that perhaps I would not be able to generate new bitmaps from the original - you can - thankyou On Feb 27, 1:19 pm, Alexey Krasnoriadtsev ale...@agilefusion.com wrote: There best working approach is to only load Bounds of the image, and then use scale to load the Bitmap of the needed size. This way you never load the full-size bitmap in the memory. http://code.google.com/intl/ja/android/reference/android/graphics/Bit... get the bounds, and then use those to calculate the appropriate sample size. On Feb 26, 2:36 pm, mark.ka...@gmail.com wrote: I'm just saying there have been a number of threads on this issue, I've had out of memory problems when processing bitmaps, and so have many other developers. It looks to me like a bug IMHO. I hope this problem will be resolved at some point. On Feb 26, 2:02 pm, bra...@gmail.com peacoc...@gmail.com wrote: If that is the case then why does calling myBitmap.recycle not give me that memory back to use for the next time I go into an edit. On Feb 26, 4:59 pm, Romain Guy romain...@google.com wrote: BitmapFactory does NOT leak Bitmaps. A 2056x1536 opaque image requires 6 MB of RAM. An application has 16 MB max. Do the math. On Thu, Feb 26, 2009 at 1:50 PM, mark.ka...@gmail.com wrote: Are you using BitmapFactory? There have been a number of threads about memory leaks, or similar problems when using BitmapFactory to process bitmaps. Using Bitmap.recycle may mitigate, but not eliminate these types of problems. M On Feb 26, 11:39 am, Mattaku Betsujin mattaku.betsu...@gmail.com wrote: I think the best solution to handle very large bitmaps is to be able to decode only a small chunk of the bitmap at a time and process it. Does anyone know if the existing Android API can support this? If not, probably one solution is to write a smart decoder (in Java, so slow :-( ) that can decode a small chunk. On Thu, Feb 26, 2009 at 11:32 AM, Tomei Ningen tomei.nin...@yahoo.comwrote: You're running into memory fragmentation problems. Bitmap memory is not allocated from the Java object heap. Instead, it's allocated from the 'malloc' heap. That's why you don't see the Java heap expanding. How big is your bitmap? If you're processing JPEG files, probably it will be better to read the thumbnail directly from the JPEG file. This way you don't need to create the Bitmap at all. On Feb 26, 9:47 am, bra...@gmail.com peacoc...@gmail.com wrote: Ok I am at the end of my rope. I am doing some image processing. I have a large image file which I open and create a smaller bitmap from. At the end of processing I call recycle on everything. I null everything. I run GC manually. I then try edit another image and I get an out of VM memory error. Bitmap exceeds etc etc. I am looking at the heap and the secone edit doesnt seem to cause it to increase at all. What else can I do. Surely google cannot possibly be suggesting that we can open one large bitmap per session and thats it?- Hide quoted text - - Show quoted text - -- Romain Guy Android framework engineer romain...@android.com Note: please don't send private questions to me, as I don't have time to provide private support. All such questions should be posted on public forums, where I and others can see and answer them- Hide quoted text - - Show quoted text - --~--~-~--~~~---~--~~ 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: Bitmap Memory
I have to agree. I am literally calling recycle() on every bitmap then I set them all to null then I run Garbage collection I can edit maybe two images and then death. If I reduce the size of the final image I can edit more - but still dies. After the force close it seems like the memory gets freed and I can edit again. If that aint a memory leak I dont know what is. On Feb 26, 5:36 pm, mark.ka...@gmail.com wrote: I'm just saying there have been a number of threads on this issue, I've had out of memory problems when processing bitmaps, and so have many other developers. It looks to me like a bug IMHO. I hope this problem will be resolved at some point. On Feb 26, 2:02 pm, bra...@gmail.com peacoc...@gmail.com wrote: If that is the case then why does calling myBitmap.recycle not give me that memory back to use for the next time I go into an edit. On Feb 26, 4:59 pm, Romain Guy romain...@google.com wrote: BitmapFactory does NOT leak Bitmaps. A 2056x1536 opaque image requires 6 MB of RAM. An application has 16 MB max. Do the math. On Thu, Feb 26, 2009 at 1:50 PM, mark.ka...@gmail.com wrote: Are you using BitmapFactory? There have been a number of threads about memory leaks, or similar problems when using BitmapFactory to process bitmaps. Using Bitmap.recycle may mitigate, but not eliminate these types of problems. M On Feb 26, 11:39 am, Mattaku Betsujin mattaku.betsu...@gmail.com wrote: I think the best solution to handle very large bitmaps is to be able to decode only a small chunk of the bitmap at a time and process it. Does anyone know if the existing Android API can support this? If not, probably one solution is to write a smart decoder (in Java, so slow :-( ) that can decode a small chunk. On Thu, Feb 26, 2009 at 11:32 AM, Tomei Ningen tomei.nin...@yahoo.comwrote: You're running into memory fragmentation problems. Bitmap memory is not allocated from the Java object heap. Instead, it's allocated from the 'malloc' heap. That's why you don't see the Java heap expanding. How big is your bitmap? If you're processing JPEG files, probably it will be better to read the thumbnail directly from the JPEG file. This way you don't need to create the Bitmap at all. On Feb 26, 9:47 am, bra...@gmail.com peacoc...@gmail.com wrote: Ok I am at the end of my rope. I am doing some image processing. I have a large image file which I open and create a smaller bitmap from. At the end of processing I call recycle on everything. I null everything. I run GC manually. I then try edit another image and I get an out of VM memory error. Bitmap exceeds etc etc. I am looking at the heap and the secone edit doesnt seem to cause it to increase at all. What else can I do. Surely google cannot possibly be suggesting that we can open one large bitmap per session and thats it?- Hide quoted text - - Show quoted text - -- Romain Guy Android framework engineer romain...@android.com Note: please don't send private questions to me, as I don't have time to provide private support. All such questions should be posted on public forums, where I and others can see and answer them- Hide quoted text - - Show quoted text - --~--~-~--~~~---~--~~ 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: Bitmap Memory
bra...@gmail.com wrote: I have to agree. I am literally calling recycle() on every bitmap then I set them all to null then I run Garbage collection I can edit maybe two images and then death. If I reduce the size of the final image I can edit more - but still dies. After the force close it seems like the memory gets freed and I can edit again. If that aint a memory leak I dont know what is. On Feb 26, 5:36 pm, mark.ka...@gmail.com wrote: I'm just saying there have been a number of threads on this issue, I've had out of memory problems when processing bitmaps, and so have many other developers. It looks to me like a bug IMHO. I hope this problem will be resolved at some point. Solving your problem will be faster if you can supply a sample project that demonstrates the phenomenon. Post an issue to http://b.android.com with the sample project, and mention the issue number here once it's posted. That way, we can take a look at what you are doing and see if we can replicate the problem, if there are other ways of potentially mitigating it, etc. -- Mark Murphy (a Commons Guy) http://commonsware.com _The Busy Coder's Guide to Android Development_ Version 2.0 Published! --~--~-~--~~~---~--~~ 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: Bitmap Memory
You're running into memory fragmentation problems. Bitmap memory is not allocated from the Java object heap. Instead, it's allocated from the 'malloc' heap. That's why you don't see the Java heap expanding. How big is your bitmap? If you're processing JPEG files, probably it will be better to read the thumbnail directly from the JPEG file. This way you don't need to create the Bitmap at all. On Feb 26, 9:47 am, bra...@gmail.com peacoc...@gmail.com wrote: Ok I am at the end of my rope. I am doing some image processing. I have a large image file which I open and create a smaller bitmap from. At the end of processing I call recycle on everything. I null everything. I run GC manually. I then try edit another image and I get an out of VM memory error. Bitmap exceeds etc etc. I am looking at the heap and the secone edit doesnt seem to cause it to increase at all. What else can I do. Surely google cannot possibly be suggesting that we can open one large bitmap per session and thats it? --~--~-~--~~~---~--~~ 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: Bitmap Memory
I think the best solution to handle very large bitmaps is to be able to decode only a small chunk of the bitmap at a time and process it. Does anyone know if the existing Android API can support this? If not, probably one solution is to write a smart decoder (in Java, so slow :-( ) that can decode a small chunk. On Thu, Feb 26, 2009 at 11:32 AM, Tomei Ningen tomei.nin...@yahoo.comwrote: You're running into memory fragmentation problems. Bitmap memory is not allocated from the Java object heap. Instead, it's allocated from the 'malloc' heap. That's why you don't see the Java heap expanding. How big is your bitmap? If you're processing JPEG files, probably it will be better to read the thumbnail directly from the JPEG file. This way you don't need to create the Bitmap at all. On Feb 26, 9:47 am, bra...@gmail.com peacoc...@gmail.com wrote: Ok I am at the end of my rope. I am doing some image processing. I have a large image file which I open and create a smaller bitmap from. At the end of processing I call recycle on everything. I null everything. I run GC manually. I then try edit another image and I get an out of VM memory error. Bitmap exceeds etc etc. I am looking at the heap and the secone edit doesnt seem to cause it to increase at all. What else can I do. Surely google cannot possibly be suggesting that we can open one large bitmap per session and thats it? --~--~-~--~~~---~--~~ 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: Bitmap Memory
The bitmap is a standard large size image as per taken from the camera. I can generate the screen size image using similar code to the gallery. The problem is that I want to save the final image at normal size (2056x1536, hell I would even settle for 1024x768). To do that I need to create a second bitmap that I can use as the canvas - this is where it always dies. I have code that does pixel by pixel translation but its considerably slower than using colormatrixes. and a canvas. On Feb 26, 2:39 pm, Mattaku Betsujin mattaku.betsu...@gmail.com wrote: I think the best solution to handle very large bitmaps is to be able to decode only a small chunk of the bitmap at a time and process it. Does anyone know if the existing Android API can support this? If not, probably one solution is to write a smart decoder (in Java, so slow :-( ) that can decode a small chunk. On Thu, Feb 26, 2009 at 11:32 AM, Tomei Ningen tomei.nin...@yahoo.comwrote: You're running into memory fragmentation problems. Bitmap memory is not allocated from the Java object heap. Instead, it's allocated from the 'malloc' heap. That's why you don't see the Java heap expanding. How big is your bitmap? If you're processing JPEG files, probably it will be better to read the thumbnail directly from the JPEG file. This way you don't need to create the Bitmap at all. On Feb 26, 9:47 am, bra...@gmail.com peacoc...@gmail.com wrote: Ok I am at the end of my rope. I am doing some image processing. I have a large image file which I open and create a smaller bitmap from. At the end of processing I call recycle on everything. I null everything. I run GC manually. I then try edit another image and I get an out of VM memory error. Bitmap exceeds etc etc. I am looking at the heap and the secone edit doesnt seem to cause it to increase at all. What else can I do. Surely google cannot possibly be suggesting that we can open one large bitmap per session and thats it? --~--~-~--~~~---~--~~ 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: Bitmap Memory
Are you using BitmapFactory? There have been a number of threads about memory leaks, or similar problems when using BitmapFactory to process bitmaps. Using Bitmap.recycle may mitigate, but not eliminate these types of problems. M On Feb 26, 11:39 am, Mattaku Betsujin mattaku.betsu...@gmail.com wrote: I think the best solution to handle very large bitmaps is to be able to decode only a small chunk of the bitmap at a time and process it. Does anyone know if the existing Android API can support this? If not, probably one solution is to write a smart decoder (in Java, so slow :-( ) that can decode a small chunk. On Thu, Feb 26, 2009 at 11:32 AM, Tomei Ningen tomei.nin...@yahoo.comwrote: You're running into memory fragmentation problems. Bitmap memory is not allocated from the Java object heap. Instead, it's allocated from the 'malloc' heap. That's why you don't see the Java heap expanding. How big is your bitmap? If you're processing JPEG files, probably it will be better to read the thumbnail directly from the JPEG file. This way you don't need to create the Bitmap at all. On Feb 26, 9:47 am, bra...@gmail.com peacoc...@gmail.com wrote: Ok I am at the end of my rope. I am doing some image processing. I have a large image file which I open and create a smaller bitmap from. At the end of processing I call recycle on everything. I null everything. I run GC manually. I then try edit another image and I get an out of VM memory error. Bitmap exceeds etc etc. I am looking at the heap and the secone edit doesnt seem to cause it to increase at all. What else can I do. Surely google cannot possibly be suggesting that we can open one large bitmap per session and thats it?- Hide quoted text - - Show quoted text - --~--~-~--~~~---~--~~ 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: Bitmap Memory
BitmapFactory does NOT leak Bitmaps. A 2056x1536 opaque image requires 6 MB of RAM. An application has 16 MB max. Do the math. On Thu, Feb 26, 2009 at 1:50 PM, mark.ka...@gmail.com wrote: Are you using BitmapFactory? There have been a number of threads about memory leaks, or similar problems when using BitmapFactory to process bitmaps. Using Bitmap.recycle may mitigate, but not eliminate these types of problems. M On Feb 26, 11:39 am, Mattaku Betsujin mattaku.betsu...@gmail.com wrote: I think the best solution to handle very large bitmaps is to be able to decode only a small chunk of the bitmap at a time and process it. Does anyone know if the existing Android API can support this? If not, probably one solution is to write a smart decoder (in Java, so slow :-( ) that can decode a small chunk. On Thu, Feb 26, 2009 at 11:32 AM, Tomei Ningen tomei.nin...@yahoo.comwrote: You're running into memory fragmentation problems. Bitmap memory is not allocated from the Java object heap. Instead, it's allocated from the 'malloc' heap. That's why you don't see the Java heap expanding. How big is your bitmap? If you're processing JPEG files, probably it will be better to read the thumbnail directly from the JPEG file. This way you don't need to create the Bitmap at all. On Feb 26, 9:47 am, bra...@gmail.com peacoc...@gmail.com wrote: Ok I am at the end of my rope. I am doing some image processing. I have a large image file which I open and create a smaller bitmap from. At the end of processing I call recycle on everything. I null everything. I run GC manually. I then try edit another image and I get an out of VM memory error. Bitmap exceeds etc etc. I am looking at the heap and the secone edit doesnt seem to cause it to increase at all. What else can I do. Surely google cannot possibly be suggesting that we can open one large bitmap per session and thats it?- Hide quoted text - - Show quoted text - -- Romain Guy Android framework engineer romain...@android.com Note: please don't send private questions to me, as I don't have time to provide private support. 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: Bitmap Memory
If that is the case then why does calling myBitmap.recycle not give me that memory back to use for the next time I go into an edit. On Feb 26, 4:59 pm, Romain Guy romain...@google.com wrote: BitmapFactory does NOT leak Bitmaps. A 2056x1536 opaque image requires 6 MB of RAM. An application has 16 MB max. Do the math. On Thu, Feb 26, 2009 at 1:50 PM, mark.ka...@gmail.com wrote: Are you using BitmapFactory? There have been a number of threads about memory leaks, or similar problems when using BitmapFactory to process bitmaps. Using Bitmap.recycle may mitigate, but not eliminate these types of problems. M On Feb 26, 11:39 am, Mattaku Betsujin mattaku.betsu...@gmail.com wrote: I think the best solution to handle very large bitmaps is to be able to decode only a small chunk of the bitmap at a time and process it. Does anyone know if the existing Android API can support this? If not, probably one solution is to write a smart decoder (in Java, so slow :-( ) that can decode a small chunk. On Thu, Feb 26, 2009 at 11:32 AM, Tomei Ningen tomei.nin...@yahoo.comwrote: You're running into memory fragmentation problems. Bitmap memory is not allocated from the Java object heap. Instead, it's allocated from the 'malloc' heap. That's why you don't see the Java heap expanding. How big is your bitmap? If you're processing JPEG files, probably it will be better to read the thumbnail directly from the JPEG file. This way you don't need to create the Bitmap at all. On Feb 26, 9:47 am, bra...@gmail.com peacoc...@gmail.com wrote: Ok I am at the end of my rope. I am doing some image processing. I have a large image file which I open and create a smaller bitmap from. At the end of processing I call recycle on everything. I null everything. I run GC manually. I then try edit another image and I get an out of VM memory error. Bitmap exceeds etc etc. I am looking at the heap and the secone edit doesnt seem to cause it to increase at all. What else can I do. Surely google cannot possibly be suggesting that we can open one large bitmap per session and thats it?- Hide quoted text - - Show quoted text - -- Romain Guy Android framework engineer romain...@android.com Note: please don't send private questions to me, as I don't have time to provide private support. 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: Bitmap Memory
I'm just saying there have been a number of threads on this issue, I've had out of memory problems when processing bitmaps, and so have many other developers. It looks to me like a bug IMHO. I hope this problem will be resolved at some point. On Feb 26, 2:02 pm, bra...@gmail.com peacoc...@gmail.com wrote: If that is the case then why does calling myBitmap.recycle not give me that memory back to use for the next time I go into an edit. On Feb 26, 4:59 pm, Romain Guy romain...@google.com wrote: BitmapFactory does NOT leak Bitmaps. A 2056x1536 opaque image requires 6 MB of RAM. An application has 16 MB max. Do the math. On Thu, Feb 26, 2009 at 1:50 PM, mark.ka...@gmail.com wrote: Are you using BitmapFactory? There have been a number of threads about memory leaks, or similar problems when using BitmapFactory to process bitmaps. Using Bitmap.recycle may mitigate, but not eliminate these types of problems. M On Feb 26, 11:39 am, Mattaku Betsujin mattaku.betsu...@gmail.com wrote: I think the best solution to handle very large bitmaps is to be able to decode only a small chunk of the bitmap at a time and process it. Does anyone know if the existing Android API can support this? If not, probably one solution is to write a smart decoder (in Java, so slow :-( ) that can decode a small chunk. On Thu, Feb 26, 2009 at 11:32 AM, Tomei Ningen tomei.nin...@yahoo.comwrote: You're running into memory fragmentation problems. Bitmap memory is not allocated from the Java object heap. Instead, it's allocated from the 'malloc' heap. That's why you don't see the Java heap expanding. How big is your bitmap? If you're processing JPEG files, probably it will be better to read the thumbnail directly from the JPEG file. This way you don't need to create the Bitmap at all. On Feb 26, 9:47 am, bra...@gmail.com peacoc...@gmail.com wrote: Ok I am at the end of my rope. I am doing some image processing. I have a large image file which I open and create a smaller bitmap from. At the end of processing I call recycle on everything. I null everything. I run GC manually. I then try edit another image and I get an out of VM memory error. Bitmap exceeds etc etc. I am looking at the heap and the secone edit doesnt seem to cause it to increase at all. What else can I do. Surely google cannot possibly be suggesting that we can open one large bitmap per session and thats it?- Hide quoted text - - Show quoted text - -- Romain Guy Android framework engineer romain...@android.com Note: please don't send private questions to me, as I don't have time to provide private support. All such questions should be posted on public forums, where I and others can see and answer them- Hide quoted text - - Show quoted text - --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
