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.)- SamiOn 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
regards,
suresh chandgude