When creating a sized (e.g. `400px` x `300px`) `Su...

# compose

[Per Jansson]

When creating a sized (e.g. 400px x 300px) SurfaceView any idea why on Android API 27, but not on API 33, I need to add clip modifier to have surface stay inside the size and not fill the whole screen with black (possible a background color)?

[Per Jansson]

I’m building a feature to display a video inside a small window and without the clip modifier it looks like this on API 27. The video still stays inside the parent composable limits (in this case 400px x 300px) but the black part should not be there covering the other composables.

[Per Jansson]

I works nicely if I add a clip modifier, than the black part is not there and the rest of the app is showing nicely below.

[Per Jansson]

Is this possible what the newly added AndroidEmbeddedExternalSurface could help address, to “sandwich” this video playing surface in between other composables?

I have not tried it yet, and was a bit concerned how it would perform to use that to play video since the docs mentions:

This means that graphics composition is handled like any other UI widget, using the GPU. This can lead to increased power and memory bandwidth usage compared to AndroidExternalSurface. It is therefore recommended to use AndroidExternalSurface over AndroidEmbeddedExternalSurface whenever possible.

[romainguy]

The embedded variant is a TextureView, so yes. But please note it comes at a cost

[romainguy]

AndroidExternalSurface is a SurfaceView btw. With a nicer API :)

[Per Jansson]

Yeah I checked under the hood that it was wrapping SurfaceView with a cleaner API. 🙂

Now I also remember that I actually did test with a TextureView a week back, and it did not need the clip modifier, but I had to abort that track since TextureView does not support playing DRM protected media if I’m not mistaken. So in that case AndroidEmbeddedExternalSurface would not work either.

[romainguy]

Protected content should be supported now if the producer sets the appropriate bit

[romainguy]

Cf https://source.android.com/docs/core/graphics/arch-st

[Per Jansson]

Ok, will check that out. 👍

[Per Jansson]

But do you have any idea why the clip modifier is needed for older Android APIs if using the SurfaceView? I think it’s an OK tradeoff to have it there since it does the job, but would be nice to know why it’s needed.

[romainguy]

It should not be needed at all given how SurfaceView works. Could be a bug specific to that API level + Compose? Or a mismatch between the size of your SurfaceView and the fixed size set on the Surface itself

[Per Jansson]

We do have some custom logic to set a fixed size on the surface, but even without that code, or setting a smaller surface than the 400px x 300px surfaceview, the black part still appears.