When creating a sized (e.g. `400px` x `300px`) `SurfaceView` any idea why on Android API 27, but not...
p
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)?
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.
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.
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.
r
The embedded variant is a TextureView, so yes. But please note it comes at a cost
AndroidExternalSurface is a SurfaceView btw. With a nicer API :)
p
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.
r
Protected content should be supported now if the producer sets the appropriate bit
p
Ok, will check that out. 👍
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.
r
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
p
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.