search

chrisbanes / Android-BitmapCache

Android-BitmapCache is a specialised cache, for use with Android Bitmap objects.
834 stars 224 forks source link

Cache the Bitmap instead of the BitmapDrawable? #8

Closed curioustechizen closed 11 years ago

curioustechizen commented 11 years ago

Is there a specific reason that BitmapLruCache caches the BitmapDrawables as opposed to the Bitmap objects themselves?

I want to use this library for caching decoded resources that will eventually be drawn on canvas (canvas.drawBitmap()). My custom View does not have a drawable to speak of. I could still use the CacheableBitmapDrawable just for the cache (and then extract out the Bitmap from the drawable that I get from the cache), but this does not seem clean.

chrisbanes commented 11 years ago

How do you plan on letting each Drawable cache itself?

curioustechizen commented 11 years ago

@chrisbanes I'm not sure I understand your question. The thing is there is a case where I don't have a drawable at all. I have a custom view that extends View. In the constructor, I am currently using BitmapFactory.decode to decode a resource from the drawable-*dpi folders. This returns a Bitmap object which I then pass in to canvas.drawBitmap() in my onDraw() method.

Probably the CacheableBitmapWrapper might have been useful. But it has been removed now. Is there a specific reason it was removed?

chrisbanes commented 11 years ago

CacheableBitmapDrawable replaced CacheableBitmapWrapper. It does exactly the same job, except that ImageView, etc, can use CacheableBitmapDrawable without having to unwrap.

My question was basically asking something can't cache itself. There needs to be something 'higher' level which decides what is cached, and what is evicted.

You can still use the LruCache, just use decode your resource and then put it in the cache via: BitmapLruCache.put(String, Bitmap)

curioustechizen commented 11 years ago

Ah okay .. I see your point now. Thanks.