BlurTransformation leak?

[fougere-mike]

Device: NVIDIA SHIELD TV
Android: 7.0

Hi, @wasabeef, I've been using glide-transformations (v2.0.2) along with Glide (v3.7.0) for quite some time with no issues. Thanks for taking the time to open source this, its been great so far.

I recently upgraded to the latest Glide (4.6.1), and glide-transformations (v3.1.1) and I'm seeing what appears to be a native memory leak. It's a bit strange though; the app never crashes with OutOfMemory, and the resource monitor shows that memory use does not appear to be growing continuously (these are the "typical" numbers: java: 70-90MB, native: 15-20MB, graphic: 60-80MB).

My app uses BlurTransformation quite frequently as the user navigates. Its not uncommon for an extended user session to result in dozens of blur calls (note: only a single blurred image is ever displayed).

After ~50 uses of the BlurTransformation, I start seeing a tonne of blocking GC NativeAllocs in the logs:

04-05 16:31:39.865 18595-18751/com.example.test I/art: Starting a blocking GC NativeAlloc
04-05 16:31:39.866 18595-18751/com.example.test I/art: Starting a blocking GC NativeAlloc
04-05 16:31:39.905 18595-18751/com.example.test I/art: Starting a blocking GC NativeAlloc
04-05 16:31:39.905 18595-18751/com.example.test I/art: Starting a blocking GC NativeAlloc
04-05 16:31:39.943 18595-18751/com.example.test I/art: Starting a blocking GC NativeAlloc
04-05 16:31:39.944 18595-18751/com.example.test I/art: Starting a blocking GC NativeAlloc
04-05 16:31:39.981 18595-18751/com.example.test I/art: Starting a blocking GC NativeAlloc
04-05 16:31:39.982 18595-18751/com.example.test I/art: Starting a blocking GC NativeAlloc
04-05 16:31:40.017 18595-18751/com.example.test I/art: Starting a blocking GC NativeAlloc
04-05 16:31:40.018 18595-18751/com.example.test I/art: Starting a blocking GC NativeAlloc
04-05 16:31:40.060 18595-18751/com.example.test I/art: Starting a blocking GC NativeAlloc
04-05 16:31:40.060 18595-18751/com.example.test I/art: Starting a blocking GC NativeAlloc
04-05 16:31:40.096 18595-18751/com.example.test I/art: Starting a blocking GC NativeAlloc
04-05 16:31:40.096 18595-18751/com.example.test I/art: Starting a blocking GC NativeAlloc
04-05 16:31:40.133 18595-18595/com.example.test I/art: Starting a blocking GC NativeAlloc
04-05 16:31:40.133 18595-18595/com.example.test I/art: Starting a blocking GC NativeAlloc
04-05 16:31:40.603 18595-18595/com.example.test I/art: Starting a blocking GC NativeAlloc
04-05 16:31:40.603 18595-18595/com.example.test I/art: Starting a blocking GC NativeAlloc

This causes the app performance to degrade to the point where its basically unusable (however, it doesn't crash with OOM, just takes a very long time to make new allocations).

At first, I had a really hard time pinning it down. After googling a bit, I found this issue: #111, which prompted me to try disabling the blur effect, which made the problem go away.

It's still possible in my mind that this isn't related to glide-transformations at all, but I'd like your input. It looks to me like this may actually be a RenderScript bug.

Here's how I'm using the transformation:

// During view initialisation:
int blackTintResource = ContextCompat.getColor(getContext(), R.color.background_image_view_dark_tint);
mBlurTransform   = new BlurTransformation(MAXIMUM_BLUR_RADIUS);
mDarkenTransform = new ColorFilterTransformation(blackTintResource);

// Later, each time a new image is applied:
final ImageView backgroundView = (ImageView) mViewSwitcher.getNextView();

RequestOptions options = RequestOptions.noAnimation()
        .override(DEFAULT_DOWNSCALE_WIDTH, DEFAULT_DOWNSCALE_HEIGHT)
        .error(R.drawable.placeholder_background_dark_hd)
        .transforms(mBlurTransform, mDarkenTransform);

mImageRequestManager = Glide.with(getContext());
mImageRequestManager
        .load(url)
        .apply(options)
        .listener(new RequestListener<Drawable>() {
            @Override
            public boolean onLoadFailed(@Nullable GlideException e, Object model, Target<Drawable> target, boolean isFirstResource) {
                mViewSwitcher.showNext();
                return false;
            }

            @Override
            public boolean onResourceReady(Drawable resource, Object model, Target<Drawable> target, DataSource dataSource, boolean isFirstResource) {
                mViewSwitcher.showNext();
                return false;
            }
        })
        .into(backgroundView);

Please let me know if I've omitted any important information, or if there are any additional tests I could do to track this down.

Cheers.

[wasabeef]

@fougere-mike

Thank you for your report.
Can you try new version? I just released v3.2.0

[fougere-mike]

@wasabeef Hi, thanks for the quick response. v3.2.0 resolves the issue.

While I was looking into this, I discovered that the issue is also resolved by using the RenderScript support library instead of the one packaged on the device:

import android.support.v8.renderscript.Allocation;
import android.support.v8.renderscript.BaseObj;
import android.support.v8.renderscript.Element;
import android.support.v8.renderscript.RSRuntimeException;
import android.support.v8.renderscript.RenderScript;
import android.support.v8.renderscript.ScriptIntrinsicBlur;

It seems that the RenderScript implementation packaged on the NVIDIA SHIELD TV is not working correctly. However, since the support library version does appear to work, I'd prefer to use it instead of FastBlur since it should have better performance.

To that end, I've written modified versions of BlurTransformation and RSBlur (SupportBlurTransformation, SupportRSBlur) which use the support renderscript library. They are essentially copy-paste with the imports changed to include support.v8.

Let me know if you'd be open to a pull request with these new classes. I can understand if your decision for this library is to remove RenderScript entirely; in that case, I can come up with my own solution.

Thanks!

[wasabeef]

Before, I used the Support v8 RenderScript 817b138
Even with that, another problem occurred and I quit using.

But Your SupportBlurTransformation idea is so good.
I welcome RP at any time.

[fougere-mike]

I've opened a pr with the SupportBlurTransformation: #125

Closing since this is resolved in the latest glide-transformations release.