getAlphaSafeBitmap and getAlphaSafeConfig should be public for use in custom transforms

[mcclure]

trafficstars

Glide has a documented feature Custom Transforms. There is no sample code, but the RoundedCorners class provides an adequate example for anyone wanting to make their own. However, reproducing RoundedCorners in user code— or in general, creating almost any useful Custom Transform— requires getAlphaSafeBitmap and getAlphaSafeConfig from TransformationUtils.java. These methods are private. This means Custom Transformations currently cannot have performance parity with Glide's builtin transformations.

I recently attempted to make a custom transform in a PR to an Android app. Because of the private method problem, I had to cut and paste the entire getAlphaSafeBitmap and getAlphaSafeConfig methods into our code. Because our app is written in Kotlin, this was impractical.

Expected behavior: Make TransformationUtils.getAlphaSafeBitmap and TransformationUtils.getAlphaSafeConfig public.

Glide Version: 4.13.1 Integration libraries: No Device/Android Version: n/a, issue is API design

[sjudd]

I totally agree that you'd need these methods to implement a similarly sane Transformation. However, given a series of improvements in the framework, can you just allocate a new Bitmap instead of using the BitmapPool?

I haven't had time to explore it fully, but I suspect on Art devices there's relatively little penalty to skipping resource re-use. So in the future I'd like to move away from having the BitmapPool at all, at least on newer versions. Resource re-use adds complexity (like these methods) and also lots of potential for error due to reference counting issues.

[mcclure]

As just a library user, I don't know. All I know is that the Glide code does it this way so my assumption is if they do it this way there's some good reason. So in the absence of blessed sample code, if I break from the way the Glide code does it, I'd want to know why I did it different.

In the Tusky PR I think using the pool was advantageous because the custom transform was not very fast to calculate (human noticeable amounts of time, though this may have been because the image was higher resolution than it strictly needed to be) but it was very likely the user would close then reopen the pane containing the custom transform. So my intuition is if it didn't have to recalculate on dismiss/reopen that sounds like a win.

For full disclosure the Tusky PR I was doing all this for got refactored and we no longer are using a custom transform, we are doing it a different way. But if we did use a custom transform for something in future it seems like there are some missing pieces (in either docs or public interface) to do it practically.

[sjudd]

There is simple sample code here: https://bumptech.github.io/glide/doc/transformations.html#custom-transformations. That does not use the methods you mention.

Just to clarify - using the BitmapPool will not make your transformation faster. All it does is avoid some garbage collection overhead by re-using an existing Bitmap instead of allocating a new one. Even on older devices the allocation was usually fast, it's just that it could incur significant GC penalties on dalvik devices.