Yeah, I was assuming that the space for the bitmap is allocated in Java heap, without thinking that many phones allocate graphics separately. Obviously, if the bitmap is allocated outside of the Java heap then freeMemory() does you zero good. But my point was that freeMemory() only returns the amount of heap not allocated to objects at the moment. If there is heap allocated to "dead" objects (that would be collected by a GC) then that space is considered "allocated", from the standpoint of freeMemory(). And, of course, there's no way to know how much "dead" heap storage there is without actually running GC.
So whether or not the bitmap is allocated in Java heap, freeMemory() is not real useful, at least not without actually running a (full) GC cycle first. On Jul 24, 5:20 pm, Streets Of Boston <[email protected]> wrote: > First a small correction on DanH's reply, ARGB_8888 uses 32 bits (4 > bytes), not 64 bits. > > The memory used by a Bitmap is roughly Width*Height*Depth bytes. (e.g. > a 1MPixel image in RGB_565 uses 2MByte of memory). I say roughly, > because the Bitmap object itself, holding the raw data, occupies a few > bytes itself. > > The problem is that the (garbage collector of) DalvikVM does not 'see' > the raw image data. It only sees the the memory usage of the Bitmap > object without the raw data (a few bytes). That's why the call to > 'freeMemory()' does not seem correct. It only reports the difference > between the max available memory minus the memory used by Java objects > (which does not include raw image data). > > However, the raw image data does affect the memory usage of your app's > Linux process, which is limited to either 16MByte or 24MByte. > > E.g. if your app's free memory is 1.5MByte and you create a 2MByte > Bitmap, the DalvikVM does not see the need to run the garbage > collector to free up old un-referenced objects, because to DalvikVM it > looks like it only needs to create a few bytes for the Bitmap object > itself and does not see the danger of a possible out-of-memory > situation. > > In my image-editing app, i try to mitigate this (not quite solve it), > by calling a System.gc() just before creating a (relatively) large > Bitmap. This reduces the chance of an out-of-memory error. > > On Jul 24, 2:03 pm, ReyLith <[email protected]> wrote: > > > First of all thank you very much everyone for your help. > > > I continue with a problem. I use Runtime.getRuntime().freeMemory() for > > obtain the free memory and compare it with the real Bitmap memory. > > Sometimes I get a free memory less than that occupied by the image. > > However, if I remove the restriction on the size of the image, I can > > work with it without any problem. Am I using an incorrect function to > > get the free memory?. Should I use another function? > > > Thank you very much in advance. > > > On 23 jul, 20:40, DanH <[email protected]> wrote: > > > > Close as I can tell, you use a BitmapFactory.Options and put a > > > BitmapConfig constant in that that specifies the type of internal > > > representation you want. If you use ARGB_8888 then each pixel will be > > > 64 bits. ARGB_4444 -- 32 bits, RGB_565 -- 16 bits. > > > > On Jul 23, 12:21 pm, ReyLith <[email protected]> wrote: > > > > > Thanks Nathan. > > > > > With this option I can obtain the image characteristics but I don't > > > > know the option that indicates me the depth of the pixel. Width and > > > > Height are in outWidth and outHeight but I don't know where is the > > > > depth. I thought use the getRowBytes() of Bitmap and product it with > > > > getHeight() of Bitmap, but I don't know if there is correct. > > > > > On 23 jul, 18:52, Nathan <[email protected]> wrote: > > > > > > If you can get the width and height for the image without completely > > > > > opening it, then use the width*height*depth. > > > > > > You probably have to use this option: > > > > > >http://developer.android.com/intl/de/reference/android/graphics/Bitma... > > > > > > Nathan > > > > > > On Jul 23, 9:30 am, ReyLith <[email protected]> wrote: > > > > > > > So, how can I obtain the depth for know if I can work with the > > > > > > image? > > > > > > > On 23 jul, 18:18, DanH <[email protected]> wrote: > > > > > > > > The size of an image file depends greatly on the compression > > > > > > > techniques used to create it. Virtually all image formats involve > > > > > > > some sort of compression such that the total number of bits in the > > > > > > > file is considerably less than the (width * height * depth) number > > > > > > > that represents the raw image. > > > > > > > > On Jul 23, 7:27 am, ReyLith <[email protected]> wrote: > > > > > > > > > Hi again, > > > > > > > > > I'm trying to put a message when the image is so big. For this > > > > > > > > I think > > > > > > > > to obtain the size of the file and compare it with the free > > > > > > > > memory > > > > > > > > Runtime.getRuntime().getFreeMemory()). It works well but I have > > > > > > > > a new > > > > > > > > problem. The application show an error message with some images > > > > > > > > because they are so big and the application dont't detect the > > > > > > > > problem. > > > > > > > > I research in other posts and the problem is that the file size > > > > > > > > is > > > > > > > > different from the size of the image in memory. To get the size > > > > > > > > of the > > > > > > > > image in memory I use the product getHeight () * getRowBytes () > > > > > > > > of the > > > > > > > > Bitmap class, but with some images not previously had problems, > > > > > > > > I get > > > > > > > > very large sizes, so often I get the message erroneously. > > > > > > > > > Does anyone know how could solve this problem? > > > > > > > > > Thank you very much in advance.- 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 [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
