GitLab

Ideally, during a surface swap, the new view is inserted *below* the
existing view in hwui. Then swap chromium compositor to the surface from
the new view, and only detach the existing view when chromium compositor
has swapped a frame into the surface of the new view. This should in
theory avoid flickers of blank frames during surface swaps.

This CL does various things to achieve the the above behavior:
* Insert new view below old view. New view is inserted at position 0.
* For SurfaceView that uses surface control, need retain the EGL surface
  to keep the surface alive.
* Use postOnAnimation to manipulate view tree. It is unsafe to
  add/remove child views during draw.
* Separate SurfaceData.destroy into markForDestroy and destroy.
  markForDestroy stops surface notifications. destroy will now be called
  after the first swap to remove the view from the view tree.
* Ensure surfaceDestroyed is always called in markForDestroy.
  surfaceCreated and surfaceDestroyed is not guaranteed to be paired.

And a clean up: remove all unused caller args in jni.

Note there is still no guarantee there is no flicker. There will
probably need to require more manul experimentation and manual testing.
Potential more hacks:
* TextureView may not have drawn the frame that chromium compositor
  produced. Can consider listening to TextureView's invalidate.
* SurfaceView will teardown its own surface before removing the "hole"
  it draws into hwui surface, leading to a flicker. May need to either
  avoid this or cover it up before detaching it.

Change-Id: I350f7da1890fdf72253759af00cb9f7f74dff0d3
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1830080
Commit-Queue: Bo <boliu@chromium.org>
Reviewed-by: Scott Violet <sky@chromium.org>
Cr-Commit-Position: refs/heads/master@{#701392}