8000 Request: offer a flag to avoid auto-recycling of a Bitmap instance · Issue #5506 · bumptech/glide · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Request: offer a flag to avoid auto-recycling of a Bitmap instance #5506

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
AndroidDeveloperLB opened this issue May 4, 2025 · 1 comment
Open

Request: offer a flag to avoid auto-recycling of a Bitmap instance #5506

AndroidDeveloperLB opened this issue May 4, 2025 · 1 comment

Comments

@AndroidDeveloperLB
Copy link
AndroidDeveloperLB commented May 4, 2025 •
edited
Loading 
implementation("com.github.bumptech.glide:glide:5.0.0-rc01")
ksp("com.github.bumptech.glide:ksp:5.0.0-rc01")

I use this simple call to get some Bitmap that I want to use right away in the current thread (and maybe even use it somewhere else), and as I don't want the cache to work here (I replace the same file with a different file later), I also disable it:

 val bitmap =Glide.with(applicationContext).asBitmap()
        .load(file)
        .apply(RequestOptions.centerCropTransform().skipMemoryCache(true).diskCacheStrategy(DiskCacheStrategy.NONE))
        .submit(photoThumbnailSize, photoThumbnailSize).get()
//use the bitmap right here (not into ImageView)

I've noticed that I got some crashes reported here via Crashlytics, saying the bitmap is recycled, so I can't use it...
The reason is that there is no reference anymore to the FutureTask, so Glide is auto-recycling the Bitmap:

https://bumptech.github.io/glide/doc/resourcereuse.html#reference-counting

I might be able to overcome this by copying the result bitmap while also having a reference to the task:

val futureTarget: FutureTarget<Bitmap> = Glide.with(applicationContext)
                                .asBitmap()
                                .load(file)
                                .apply(RequestOptions.centerCropTransform().skipMemoryCache(true).diskCacheStrategy(DiskCacheStrategy.NONE))
                                .submit(photoThumbnailSize, photoThumbnailSize)
val bitmap: Bitmap? = futureTarget.get()
//copy the bitmap to a new instance here, instead of using it wherever I wish...

But this is a bad workaround as it uses double the memory, and even here I'm not sure it will work. Maybe it will cause GC before I copy the Bitmap as there is no use of the "futureTarget" anymore (optimization by the GC), and recycle the Bitmap?

Anyway, please offer a way to overcome this, to let me do the decoding&downsampling operation without the danger of my bitmap being recycled by Glide.
@AndroidDeveloperLB AndroidDeveloperLB changed the title Bug: Glide sometimes recycles a Bitmap instance that I've created from it right before I'm about to use it Request: offer a flag to avoid auto-recycling of a Bitmap instance May 4, 2025
@AndroidDeveloperLB
Copy link
Author
AndroidDeveloperLB commented May 5, 2025 •
edited
Loading

It seems what I suggested as workarounds don't really work.
So now I wonder if there is any way to use Glide just for decoding with extra functionality, or I have to use real targets and have a hard reference to them all the time...

And still, the request is to be able to avoid this auto-recycling easily, without workarounds...

BTW, the docs about recycling a Bitmap says:

This is an advanced call, and normally need not be called, since the normal GC process will free up this memory when there are no more references to this bitmap.

https://developer.android.com/reference/android/graphics/Bitmap#recycle()

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@AndroidDeveloperLB
0