Use TextureView as compositing surface on Android?

[Hongbo Min]

Hi,

In the current implementation of ContentViewRenderView [1], it uses SurfaceView as the compositing surface. As we know, SurfaceView is a special View which can not be animated or transformed.

TextureView[3] can also do the same thing as SurfaceView, for example, you can render it from another separate thread, and also create a egl surface from its underlying SurfaceTexture. Moreover, TextureView can be animated and transformed.

I am curious about the question why not to use TextureView as the compositing surface instead. Is there any special concern for TextureView usage, like performance issue? Any comments are welcome.

Thanks.
Hongbo

[1] https://code.google.com/p/chromium/codesearch#chromium/src/content/public/android/java/src/org/chromium/content/browser/ContentViewRenderView.java&q=ContentViewRenderView&sq=package:chromium&l=30
[2] http://developer.android.com/reference/android/view/SurfaceView.html
[3] http://developer.android.com/reference/android/view/TextureView.html

[Sami Kyostila]

Hi Hongbo,

In fact Chrome used to use a TextureView as the compositor target surface, but we switched to SurfaceView for a few reasons:

- Because of its invalidation and buffering behavior, TextureView adds 1-3 extra frames of latency to display updates.

- TextureView is always composited using GL, whereas SurfaceTexture can be backed by a hardware overlay which uses less memory bandwidth and power.

- The internal buffer queue of TextureView can end up using more memory than a SurfaceView.

- We weren't really doing anything useful with the animation and transform capabilities of TextureView.

- Sami

[Hongbo Min]

Sami, thanks very much.

(I forgot cc to graphics-dev, thanks for your reminder:)

2014-03-10 20:23 GMT+08:00 Sami Kyostila <skyo...@google.com>:

It's true that TextureView makes it much easier to apply animations to the output from the compositor. I guess it's really up to your use case whether the downsides of TextureView are worth it. However, similar effects are possible using a browser-side compositor, but that requires more native code as you said. For the most part it isn't necessary to do a readback from SurfaceView.

A TextureView can end up being triple buffered, in which case it allocates about 3 * view_width * view_height * 4 bytes of graphics memory.

(btw, I'd prefer to have these conversations on graphics-dev@ so that others can benefit from them too.)

- Sami

On 10 March 2014 01:55, Hongbo Min <hongb...@gmail.com> wrote:

Hi, Sami

Thanks for your explanations.

Without an animation-supported View widget, the effect of tab switching implemented in Chrome browser seems to not be so straightforward, it may need to write lots of native code to achieve such an fancy effect, right? Also, it is an expensive operation to capture snapshot on a SurfaceView since it needs to read back the image from GPU memory.

I tried to replace SurfaceView with TextureView as compositing target surface, and try to apply animation and transformation on it, like scaling, fading in/out.The animating effect sounds good. It could be a desired feature for a embedder that implements a browser based on content layer.

Regarding to the memory consumption, how much would TextureView consume more than SurfaceView for a normal web page?

-Hongbo

[suresh.ch...@gmail.com]

Hi Hongbo,
I am creating android app, where I am taking camera on surfaceview, but it's preview is blurry.
If there is any solution PLEASE tell me.

regards,
suresh chandgude