The Bitmap class has a method copy() with the signature below:
public Bitmap copy(Bitmap.Config config, boolean isMutable)
Is there a performance difference between a mutable and an immutable Bitmap?
Romain Guy answered in the comments:
To answer the original question: no, there is no performance
difference. There are some optimizations we could implement for
mutable bitmaps though. Hopefully in a future release :)
There is no performance difference. This will not affect the performance of your app. If you want to perform any opration like rotation etc then i think the bitmap should be mutable...
On Application level, there is always a difference between immutable & mutable Bitmap resources.
You always get an immutable Bitmap from the resources. you need to convert them into mutable bitmap as per necessiti.
Bitmap Bitmap = BitmapFactory.decodeResource(....);
Bitmap mutableBitmap = immutableBitmap.copy(Bitmap.Config.ARGB_8888, true);
So probably there must be a performance issue in this reference.
Related
Here look at the below code,
for (String path : all_path) {
bmp = BitmapFactory.decodeFile(path);
bitmapList.add(bmp);
}
and this code is driving me crazy. As in each iteration BitmapFactory.decodeFile(path) is called and driving memory to its pick as a result OutOfMemory exception occurs. I tried to use recycle() old bitmap in the loop before decoding new bitmap but it means no sense. I searched for the answer about using bitmaps in loop but failed to find one. What should I do? anyone help please.
You are adding all bitmaps to a List. However you are using the same reference variable bmp for all bitmaps so in each iteration they get replaced.
But in the List all the bitmaps are being added. If there are many bitmaps then it will eventually result in OutOfMemoryError
Better do not add all bitmaps in a List.
Try to recycle the bitmaps you are not using.
If you use all the bitmaps than add them to a cache and use them later.
Next when you want to replace one you will replace just one not all of them.
The change from below requires a bit more work but it works as I used it with a lot of bitmaps.
Please take a look here:
I implemented once something like this:
http://developer.android.com/training/displaying-bitmaps/cache-bitmap.html
Bitmaps can be huge. Why do you need to read them all to the memory? Normaly, you would read each bitmap on demand. Optionally, you can read thumbnails, which are much less memory demanding (BitmapFactory enables you to downsize the bitmap when reading - use BitmapFactory.Options, member inSampleSize).
Read this: http://developer.android.com/training/displaying-bitmaps/index.html
One would think that the second approach would be more efficient but I can't say that I see any improvement using it. Is there a difference between the following two ? (memmory wise ofcourse)
Bitmap bm=MediaStore.Images.Thumbnails.getThumbnail(getContentResolver(), id, MediaStore.Images.Thumbnails.MINI_KIND, null);
bm=cropAndScaleBitmap(bm);
//use bm
vs
Bitmap bm=MediaStore.Images.Thumbnails.getThumbnail(getContentResolver(), id, MediaStore.Images.Thumbnails.MINI_KIND, null);
Bitmap b =cropAndScaleBitmap(bm);
bm.recycle();
//use b
Things to note here ...
Even though you have specified recycle, it will have any effect only
when the next GC is trigerred.
Other things to note
In pre-Honeycomb versions of Android the memory for bitmaps was (is) allocated from unmanaged memory.It will take at least 2 passes of GC to collect it. Another thing is - it is really difficult to trace - DDMS does not see it and neither does MAT.
Read this link https://developer.android.com/training/displaying-bitmaps/manage-memory.html. If api level >10,I don't think we need to call recycle.
Refer to this link ... It provides all details and the code sample for how to implement step by step.
https://developer.android.com/training/displaying-bitmaps/manage-memory.html
Hope this helps.
In your specific example (first one) you don't actually reuse the source, you just overwrite the value of the bm making it point to the new bitmap instead, in this case you can no longer call recycle on the source bitmap as you no longer have a reference to it.
I recommend using the second method to make sure the source bitmap is recycled.
Do I still need to call Bitmap.Dispose() after Bitmap.Recycle()? Or just Bitmap.Dispose() is enough?
According to Android documentation Bitmap.Recycle() should be enough:
Free the native object associated with this bitmap, and clear the
reference to the pixel data.
Mono for Android documentation says exactly the same.
Also, this question gets a little further on how Bitmap.Recycle works.
Another solution could be to wrap in a using statement:
using (var bm = new Bitmap(..))
{
// Do stuff with the Bitmap here
}
Just remember that when you leave the scope of the using statement, the Bitmap will probably be garbage collected. So if you are just drawing it to a Canvas or something this is a nice way to do it.
I have to draw a lot of objects on the game screen made of same Bitmap. So, I need to find a good way to reuse bitmap. I have a class where Bitmap is a field, and every object on the screen is an instance of this class (or its subclass). How can the best performance be achieved in this case?
Thanks for advices.
If you make the bitmap field static then only one instance exists. But in this case you need to manage drawing access to this object.
How about having a BitmapCache class which would be responsible for storing/caching/retrieving all the Bitmap objects.
Can someone please explain to me what a mutable bitmap is? What advantages/disadvantages or what limitations do mutable and immutable bitmaps have?
It's about the same difference as with String vs StringBuilder - String is immutable so you can't change its content (well at least not without any hacks), while for StringBuilder you can change its content.
In order to convert an immutable bitmap to a mutable one, check out this post:
https://stackoverflow.com/a/16314940/878126.
If your bitmap include mutable flag, its pixels can be change, if doesn't, pixel changings throw an error. It's the difference between them.
And here is Android: convert Immutable Bitmap into Mutable
Not sure if there is any performance gain for using immutable bitmaps.
Often immutable is just for being thread safe (or if you are going to share the image with another process, process safe)
Tries to make a new bitmap based on the dimensions of this bitmap, setting the new bitmap's config to the one specified, and then copying this bitmap's pixels into the new bitmap.
and you can set config of image.