See what I found: <Add RenderEffect API>, this makes me a little excitement :raised_hands:. I also s...

# compose

[Chachako]

See what I found: Add RenderEffect API, this makes me a little excitement 🙌. I also saw the desktop support the same effect by skija, then is it possible to be compatible with the version below android 12 (eg, through RenderScript or Vulkan)?

[mzgreen]

While it may be possible to create a compat blur for older platforms, it doesn't seem to be a part of the change you linked. See https://android-review.googlesource.com/c/platform/frameworks/support/+/1797470/1/compose/ui/ui/src/androidMain/kotlin/androidx/compose/ui/platform/RenderNodeApi23.android.kt#89

[Chachako]

Yes, I think compatibility is needed, but I don’t know why they are limited to android 12.

[Nader Jawad]

It relies on some features of skia we recently added support for in Android 12. Also it is inserted deeper within the Android graphics rendering pipeline for efficiency. Renderscript is deprecated in Android 12 and while vulkan is available on Android devices since Android N, more of the complexity revolves around rendering dynamic app content into a texture that can be consumed by other graphics facilities

[Sergey Y.]

@Nader Jawad Will we have an API to render a composable widget into a texture so that we can manipulate it later?
preferably with min sdk below 31 :(

[Chachako]

@Nader Jawad Well, can you explain whether it is possible to support blur effect for lower versions? I think compose as a separate ui framework should support this effect.

[Sergey Y.]

@Chachako All we need an API to draw composable into a bitmap, the rest is matter of technique(RenderScript, FastBlur, Native code, etc)

[Sergey Y.]

if we gonna have such API we can do anything with the bitmap

[Sergey Y.]

well of course it will cost somewhat in terms of performance with realtime processing, but it is definitely solvable, and better than having a cap to min sdk 31+

[Chachako]

@Sergey Y. You’re right. I submitted a question at that time, but until now it has not made any progress: https://issuetracker.google.com/issues/180881629

[Sergey Y.]

I wonder can we provide our instance of DrawingScope?

[Nader Jawad]

Unfortunately it's not so simple. Rendering to a Bitmap is purely software backed and is not done in hardware. Additionally some drawing operations like shadows are only supported in hardware. Rendering all of compose UI within a Bitmap before drawing to the display is very expensive.

[Sergey Y.]

Sorry if I was not able to clearly express the idea.
But, the entire UI definitely does not need to be rendered into a texture, only those nodes that we will need, for example, have a modifier which can inject our "output", our own instance of DrawingScope

[Sergey Y.]

Having that it would be simple to construct simple frame buffering mechanism, which can handle the rest.

[Chachako]

Totally agree, so we can get bitmap, and then we can do more effects as a third-party solution (even at the expense of performance)

[Nader Jawad]

It won't support all drawing operations as bitmap rendering is purely software rendered

[Sergey Y.]

I think it's okay. I was working on an SVG to bitmap renderer, it worked on multiple threads and could handle scaling with good FPS, of course I used some tricks to do this, but this is not the case.

[Chachako]

Sorry, I don’t understand the rendering mechanism of compose, but can’t compose implement a solution like android-view?

[Nader Jawad]

Github implementations of blur effects on Android that rely on bitmap are relying on the old software backed rendering pipeline on Android. Attempts to do so on compose with a composition hierarchy that leverages any graphicsLayer modifiers will crash as graphicsLayers are only supported in hardware and Bitmap based drawing is purely software based

[Sergey Y.]

yes it is a nuance.
when only hardware rendering is required.

[Sergey Y.]

and what to do, how to satisfy the intrigues of designers?
this is a rhetorical question 😒

[Nader Jawad]

Future versions of compose may introduce graphicsLayer automatically on the developers behalf even if not explicitly indicated. This can cause unexpected consequences if rendering to a bitmap directly

[Sergey Y.]

I am with both hands for such optimizations and maximum performance, but minSdkVestion 31 will not shine for at least another 5 years.

[Nader Jawad]

We are very much in support of providing support for as many Android OS versions as possible, this feature unfortunately requires more facilities of newer OS versions to function with reasonable performance and consistency. I just wanted to point out the complexities and issues regarding solutions that involve rendering to an intermediate bitmap.

[Sergey Y.]

I understand and support you. This is the way. mandalorian

[Chachako]

So, can I use the blur view implemented on Github through AndroidView?

[Sergey Y.]

you could try)

[Nader Jawad]

You would still run into similar limitations with shadow usages in Views since they internally use RenderNode as well

[Chachako]

I tried using the android view, but the problem is that the compose view obtained through decorView.draw(canvas) has not been updated. Maybe we can start from this aspect?

device-2021-08-18-151804.mp4

[Nader Jawad]

How are you transforming the view? If you are using the view based translation/rotation APIs you will need to manually invalidate to recompute the blurred overlay view. Otherwise the view contents themselves are reused and will show the same blurred content

[Chachako]

@Nader Jawad I use graphicsLayer to rotate/scale/translate, and then use composeView.draw(bitmapCanvas) to blur the content