Memory consumption

[angelolloqui]

When used together with a recycler view or alike, the bitmap created inside the drawableToBitmap does not get released properly. It is up to the system to garbage bitmaps, but as a developer you can attempt to free it by calling recycle() when not longer used. As a result, when using this library with hundreds of bitmaps in a recycler view (in my case a user list), the app frequently falls in a OOM exception, while using a regular ImageView does not.

Proposal: When assigning a drawable/bitmap/resource/.... release any previous content contained in private Bitmap image; instance variable by calling image.recycle().

[lopspower]

Thank you for this return is very interesting. There is indeed a lot of return to this level but this time the problem seems to be well identified.

In the case of this library, as I understand it, you have to release (recycle) the Bitmap image between each write in this way: civImage?.recycle()

For that I modified the loadBitmap function. Do you think this change is enough to fix the problem?

private fun loadBitmap() {
    if (civDrawable == drawable) return

    civDrawable = drawable
    civImage?.recycle()
    civImage = drawableToBitmap(civDrawable)
    updateShader()
}

[angelolloqui]

Sounds like a good fix to me, but I would need to test it and profile it to assert it has an impact

[lopspower]

I tested on my side but I can't reproduce OOM. I used the profile of memory but there is no impact with recycle(). I also tested with ImageView. The base component is less expensive in memory but it behaves in the same way, the memory does not increase no matter the number of elements in the list. So I think there is no problem with the component. The problem only comes from the size of the image that is used in it. The component is obviously more expensive than an ImageView because it does more things. I am nevertheless very interested in your analysis to see if you have the same conclusion as me.