Support for older Android systems

[gleb-skobinsky]

Many thanks to you Chris and other contributors for this awesome library! It works like charm, unlike numerous fancy, but intangible solutions available out there.
This is not an issue, but rather a feature request. How likely it is that this library may support RenderScript-based blur for the older Android versions (pre-Android 12)? Is a pull request to add such functionality something that you guys would consider?

[chrisbanes]

How likely it is that this library may support RenderScript-based blur for the older Android versions (pre-Android 12)?

Not likely, unless someone contributes it.

Is a pull request to add such functionality something that you guys would consider?

I'd definitely consider it! My only thought is that this would probably need to be opt-in.

[gleb-skobinsky]

Great, I will give it a try then sometime soon.

[iZakirSheikh]

You can try legacybackgroundBlur modifier from my lib.
Here check this article "Blurring the Lines: How to Achieve a Glassmorphic Design with Jetpack Compose " https://medium.com/proandroiddev/blurring-the-lines-how-to-achieve-a-glassmorphic-design-with-jetpack-compose-0225560c2d64

[desugar-64]

Just to add my two cents, I usually avoid using software (CPU) blurring on Android for tasks that need frequent updates. For static blur, where you blur an image or background once and leave it, it’s fine. But for real-time blur, where the background needs to update quickly with UI changes, software blur is just too resource-intensive and slow. It drains too much energy, memory, and CPU, and doesn’t perform well on less powerful devices.

It’s better to avoid CPU blurring on older APIs and use a simple scrim color instead. If it is unavoidable and you need to support blurring on APIs below 31 without sacrificing performance or energy consumption, the best approach is to use GPU-based blurring. It’s fast and power-efficient when implemented correctly, though it is more complex. I’m exploring this area, and the results are quite promising so far.

[chrisbanes]

+1 to @desugar-64. Any solution which relies on software rendering (i.e. drawing to a bitmap and using RenderScript) isn't going to be fast enough.

I'm interested to have a look at your GPU backed implementation @desugar-64. I assume that it's a OpenGL shader?

API 31+ isn't just optimal because they have RenderEffects, but because we have access to RenderNode. That makes drawing content multiple times basically free. GraphicsLayer does have a back-compat version which uses a View underneath on older platforms, but I haven't used it enough to see if there are any performance trade-offs.

[desugar-64]

Hey, @chrisbanes.

Yes, you’re correct. I’m using OpenGL ES for my implementation. I’ve written a rendering pipeline that performs post-processing on UI elements rendered into textures. Essentially, I’m using the GraphicsLayer to render UI into a surface-backed canvas, and then I use this texture for further post-processing.

I’ve open-sourced my project, and you can check it out Imla.
I update it from time to time, so feel free to explore it. I hope you find it useful 🙂.
Please note that I’m still actively working on it, so the code might not be perfectly clean yet. This is a hobby project of mine, so any feedback is welcome.