M53 average current is 308mA
M59 average current is 468mA

What device is this? When we turned on the unified pipeline we measured equivalent fullscreen power usage.

Oh right, WebView doesn't get SurfaceViews, so this is still SurfaceTexture now.

+boliu as FYI as we made this call a long time ago (no SurfaceView for WebView video playback). Frank was there any way to use the DialogSurfaces to make this happen in a cleaner way?

that's from the extra copy webview does, even ignoring the cost of not using surfaceview I think. not sure if that's actually avoidable though.

There are too many problems with using another surface on webview. Main one being there probably will be a power *regression* if you do it naively.

adding DS for WV: not without some additional platform support and / or changing the WV api, unfortunately.

avoid texture copy of video frame: new stuff in android 26 might help us here.  AImageReader / chrome's GLImageAHardwareBuffer might let us avoid it.

+ericrk: FYI, your AImageReader work might also help WebView.

Is there any solutions or workaround? M53 uses ContentVideoView in fullscreen video playing. Shall we change it back?

i don't think that changing it back is an option; the M53 pipeline doesn't exist anymore.

as for adding overlay support using DS, maybe i was being pessimistic before.  a custom DS backend that doesn't rely on Dialog might work.  as long as it supports the AndroidOverlay api, the video pipeline won't care.  i'll think about it.

however as mentioned in c#5, i'm not convinced this will guarantee any sort of power improvement.  if the additional surface causes it to run out of hardware composition lanes, then it's almost a guaranteed loss.

It's not possible to remove in all cases anyway, because the texture copy change was required to enable multiprocess on Android. At best this could only have been avoided for L and M devices.

> however as mentioned in c#5, i'm not convinced this will guarantee any sort of power improvement.  if the additional surface causes it to run out of hardware composition lanes, then it's almost a guaranteed loss.

It's worse. My concern is that if you just do things naively like how things are hooked up in chrome, then that will cause *both* surfaces to update, which is probably going to be a net lose on power.

who would be the proper owner to take this bug? 
give to boliu@ to start, please re-assign appropriately if need.

I don't see any reasonable path forward here. Unless media stops using SurfaceTexture (ie probably ship our own decoders or something), then that extra copy has to stay.

Shipping our own decoders would be worse since they wouldn't be hardware decoded. If the copy has to stay this is WontFix.

maybe vulkan will save us, in a few years...