Add API to check if Blur is supported

[Skaldebane]

Hi there!

Currently, there's no way to know if blur is supported or not, to customize the behavior (a la #398).

Because on Android, it's not just about API versions, as many low-end Android 12+ devices don't support blur for performance considerations, and thus Compose's blur becomes a no-op, and Haze draws the fallback tint.

It would be great if there's an API like Haze.isBlurSupported to know whether it's supported on the current device.

[chrisbanes]

many low-end Android 12+ devices don't support blur for performance considerations, and thus Compose's blur becomes a no-op, and Haze draws the fallback tint.

Hmmm, are you sure about that? If a device doesn't support blurring (somehow), then I don't know of a way to check at runtime.

Haze's check for whether a device supports blurring is very simple: https://github.com/chrisbanes/haze/blob/main/haze/src/androidMain/kotlin/dev/chrisbanes/haze/RenderEffect.android.kt#L99

[Skaldebane]

Oh, that's interesting. I Googled up any way to check compatibility but didn't find anything useful, so I thought Haze was doing something special there 😅

I have a Galaxy A11 running Android 12, and blurring doesn't work at all. Including my own apps, Tivi, and others.

Interestingly, the system UI has a lot of blur, but it seems to be a custom implementation by Samsung that doesn't look like a real (Gaussian?) blur.

And the fallback works just fine as well!
Maybe the isHardwareAccelerated is false for these low-end devices? No clue tbh.

[Skaldebane]

My bad, Android 12 is SDK 31, 12L is 32.

Guess I was mistaken for years 😆

[Skaldebane]

Actually, wait a second... Android 12 (SDK 31) does indeed support blur. The Compose Modifier.blur() works just fine.

I can't see any graphics-related API changes between SDK 31 and 32, and I certainly remember blurring and RenderEffects being a big thing for Android 12 (not 12L).

Is there actually any blocker to this working on Android 12 (SDK 31)?
Or is it a classic off by one error 😅 (whoopsie)

I guess I was in the same situation as the "elephant tied with a tiny rope", thinking my hardware was exempt due to its limited power, so I never tried. I also didn't find a use for blur() modifier so never tried that either. Haze was the only thing I ever tried, and it always used fallback.

Funnily, I initially made that conclusion because Tivi blurs didn't work for me 😆

[Skaldebane]

Alright, I stepped into the useGraphicsLayers function in the debugger, and force returned true to check it out...

And y'know what? Android 12 (SDK 31) is supported!

The blur works like a charm. Damn, I feel betrayed 😆

I'll open a PR with the fix.

[chrisbanes]

I haven’t tried for a while, but yes there are issues on SDK Level 31. See #77

[Skaldebane]

@chrisbanes Ah, I see now 👍🏻
Seems to work fine on my end, but it's better to keep it disabled if it's not consistently reliable.

[chrisbanes]

I’ll double check again tomorrow. Maybe there’s been some workarounds in Compose 1.7 🤷

[Skaldebane]

Yeah. Note that my device is a Samsung, and the ones mentioned in #77 are Google/AOSP, so there might be something there. Or it could be a mainline upgrade for all devices.

[Skaldebane]

Tried with an Android 12 emulator, and I can observe the freezing issue. So Compose 1.7 doesn't change much.

Taking a second look at #77, all the videos are from emulators, so could it be an emulator-specific quirk? Or it could be something in AOSP that was fixed by vendors and/or a Google Play system update.

Having data from more hardware devices would be useful. At the very least, I can confirm Samsung's skin to be working without issues.

[Skaldebane]

Alright, I tried some Firebase Remote devices with SDK 31:

1. Samsung Galaxy A51: Haze works properly, content is updated properly.
2. Google Pixel 6a: Haze works properly. And this is the closest we can be to AOSP.

There's definitely better ways to get access to more devices, but I guess this paints a good general picture of what's going on. I suspect the emulated graphics in the emulator have something to do with it, but I may be wrong about that.

Though I'd love to see a Xiaomi being tested, since they're notorious for creating their own bugs (let alone fixing AOSP ones).

[Skaldebane]

Let's continue in #77.