Dimezis / BlurView

Dynamic iOS-like blur of underlying Views for Android
Apache License 2.0
3.48k stars 331 forks source link

Blur Algorithm and Android 13 #182

Closed GuillaumeBourge closed 2 years ago

GuillaumeBourge commented 2 years ago

Please include: 1) 2.0.1 2) Pixel 6 with Android 13

We are using blurview to perform blurred overlay behind loader and dialog. It works perfectly fine until Android 13. On Android 13 when a textfield is shown and focused within Dialog with blurred background, we got a blinking background.. (the blinking/redraw seems to occurred when a letter is drawn or when the cursor blink) We are using RenderScriptBlur .setBlurAlgorithm(RenderScriptBlur(rootview.context)) but it is now deprecated. We try to switch to RenderEffectBlur (that is also deprecated ?) with setBlurAlgorithm(RenderEffectBlur(this, RenderEffectPrecision.EXACT)) and it seems to work fine (RenderEffectPrecision.DOWNSCALED make a blinks each time in every case).

My question is what script we must used ? the all two are now deprecated and android 13 seems to be tricky :( The visual render is a little bit different between the two scripts ?

Dimezis commented 2 years ago

It's actually a very complicated topic, and I kind of regret releasing the RenderEffectBlur at all.

So the RenderScriptBlur is deprecated because Google deprecated the RenderScript itself. The problem is that RenderScript now is not guaranteed to be hardware-accelerated on newer devices, it's basically up to OEMs to provide hardware support or not.

Google hasn't offered any viable alternative. The only 2 reasonable solutions, that are hardware-accelerated, are OpenGL and RenderEffect API. Of course, OpenGL could be adopted, but that would require rewriting the BlurView from scratch in a very different manner, potentially introducing a lot of new issues.

RenderEffect seemed like a much simpler alternative for newer SDKs, but because of its traits, it's causing a constant redraw of the BlurView, and doesn't seem to be faster. Plus I had to introduce a slightly different rendering pipeline, which results in potential differences between blurring algorithms.

That's why I deprecated it as well and I suggest using the old RenderScriptBlur for the time being.

I'm trying to figure out a good alternative from time to time, but I can't invest much time into this library.

If you post a video of your problem and maybe a sample project, I might be able to suggest something

Dimezis commented 2 years ago

@GuillaumeBourge Version 2.0.2 undeprecates the RenderEffectBlur back 😅 It's now completely rewritten in a much more efficient (and sane) way

GuillaumeBourge commented 2 years ago

@Dimezis Good news for your rework, but bad news your build failed :p build-logs

Dimezis commented 2 years ago

@GuillaumeBourge No worries, it doesn't matter since the Jcenter is closed and I'm not publishing artifacts there anymore. If anything, I should just disable this CI step

GuillaumeBourge commented 2 years ago

Ok we thought that was that causing our "Failed to resolve: com.github.Dimezis:BlurView:version-2.0.2" We are not able to retrieve the 2.0.2 version with gradle but not problem with the 2.0.1 :/

Dimezis commented 2 years ago

Ah, for some reason Jitpack decided to execute some unrelated tasks. Weird. Try fetching the 2.0.2 now

GuillaumeBourge commented 2 years ago

Yes it works fine now thank you :) Just to know, the blur radius is also strongly affected by you redesign ? a 25 radius 2.0.1 RenderEffectBlur seems to be ~ 6 radius 2.0.2 RenderEffectBlur It's not a problem for me, but knowing the min is 6 maybe it can be too much blurred for some usecase ?

Dimezis commented 2 years ago

It's effectively changed because of a different downsampling coefficient, yes. It's pretty heavy-handed, but most of the time people use the higher radius, which takes longer to process, so I went for a higher downsampling coefficient to mitigate it

GuillaumeBourge commented 2 years ago

Ok thank you for explanations and improvements :)