I believe if you set the SurfaceView as ContentView of the activity, you can avoid two fullscreen window cost.

But this may not be a good idea for tab activity as Chrome Home is all Java base.

For fullscreen web activity, we only need to temporarily show infobar, splashscreen and etc. I believe we can put them in an AlertDialog which has its own window. Just a thought.

I checked what happens if we have surface view only and shows alert dialogs. The memory usage is lower and the SurfaceFlinger buffers show only 3 buffers.

When alert dialog is triggered, the EGL mtrack goes up significantly for showing the dialog. This adds 3 more buffers in SurfaceFlinger for the dimensions of the dialog box. The native and java heap also increase by few MB.

When the dialog box is cleared, the EGL mtrack memory goes down a little, but not to the original value. This depends on the device. On Nexus 5, the memory goes up by 22MB on creating dialog and reduces by 8MB on clearing. On gobo device, the memory goes up by 4MB on GL mtrack and never comes back. On Pixel C tablet, the memory goes up by 20MB on native heap and there is no decrease when dialog is cleared. There is also 1-3MB increase in native heap that never comes back in all the devices. Right now by guess is that the graphics driver keeps caches view buffers allocated and freed. I haven't looked into possibilities of clearing such caches yet. 

All the devices have only 3 buffers at start and when the dialog shows has 5-6 buffers and when cleared, the number of buffers comes back to 3.

So, if the dialog window is full screen, the memory increase would be as much as triple buffering full screen resolution and when the buffers disappear the memory usage stays up. I see that the splashscreen on PWA startup does not use surface view and would trigger triple buffering on the android content view buffers and even if we call takeSurface the memory on GL mtrack memory would not go down.