A modern programming language that makes developers happier.

kotlinlang

Hey people! I was looking into <https://github.com/rive-app/rive-android|Rive> and found that they don't have a compose version of the library. I looked into if I can contribute into this project to add support for composable but I found that Compose doesn't have a <https://developer.android.com/reference/android/view/TextureView|TextureView> or a <https://developer.android.com/reference/android/view/SurfaceView|SurfaceView>. In the new 1.6 version, compose now has <https://developer.android.com/reference/kotlin/androidx/compose/foundation/package-summary#AndroidExternalSurface(androidx.compose.ui.Modifier,kotlin.Boolean,androidx.compose.ui.unit.IntSize,androidx.compose.foundation.AndroidExternalSurfaceZOrder,kotlin.Boolean,kotlin.Function1)|AndroidExternalSurface> which got me excited but when I looked into the implementation, its just a wrapper around the good old <https://developer.android.com/reference/android/view/SurfaceView|SurfaceView>. I don't know a lot about <https://developer.android.com/reference/android/view/SurfaceView|SurfaceView> so I wanted to know if anyone has an idea why the compose team went ahead with a wrapper which might introduce performance overhead because of the bridging.

It seems to be on their Roadmap, though there is not a whole lot of information on the progress, or whether they have started working on compose support at all.
See this issue for more info: <https://github.com/rive-app/rive-android/issues/259>

You might think of Jetpack Compose as a fancy custom android View, that draw content using standard canvas APIs. SurfaceView in Android is a specialized view that offers direct access to a dedicated hardware buffer, allowing for efficient drawing and manipulation of graphics. It operates at a lower level than standard views like View, providing greater control over drawing and rendering processes.

Replicating SurfaceView in Compose would require a complete overhaul using OpenGL or Vulkan, bypassing the Canvas API used in Compose's drawing system.

That's why SurfaceView/WebView/TextureView will always be basic AndroidView wrappers in Compose.
And it is completely fine.

`SurfaceView` and `TextureView` are both quite unique and can’t be replicated outside of the OS

Well, you can mostly with never APIs, but this couldn’t be backported

Also the “overhead” of the composables wrappers is close to irrelevant for those particular views

<@UJZJNF6R4> `SurfaceView` has nothing to do with OpenGL/Vulkan/Canvas

What I mean is that the only way to create a “Compose SurfaceView” is to have ComposeView inherit from SurfaceView and implement the compose renderer using some graphics API that uses the surface provided by SurfaceView. I hope you understand what I mean.

But that's not what we're discussing here

And Compose could render in a SurfaceView today just fine

Than I lost the thread :disappointed:
By rendering in a SurfaceView do you mean something like <https://developer.android.com/reference/android/view/SurfaceHolder#lockCanvas()> and replace original Compose's Canvas by this?