Doc on viz for webview

[Bo Liu]

Hi all,

Here's a design doc for "viz for webview", ie android webview supporting surface embedding:

https://docs.google.com/document/d/1s0cVEIvt8jrZpzAAHERWPSe_pjowum8RrCK1M00VzQA/edit?usp=sharing

Feel free to comment with your chromium account.

Thanks

Summary of decisions pasted from the doc:

• Add a new “viz” thread in browser process. Render thread, UI thread, renderer compositor are allowed to block on viz thread (blocking in reverse direction not allowed).

• Split viz service:

• viz::mojomCompositorFrameSink implementation, which handles SubmitCompositorFrame and BeginFrame requests from viz clients, will live on the new viz thread. There is no gpu command buffer client on this thread.

• Aggregate and DrawAndSwap on render thread. This thread can block on viz thread if needed to wait for CompositorFrames to arrive. The gpu command buffer client continues to live on this thread.

• FrameSinkManagerImpl - state tracking for frames becomes lock protected and shared between viz and render threads. As long as viz and RT does not block while holding the lock, there should be no deadlocks. Note there are other possible synchronization schemes such as blocking viz thread while RT accesses shared data. What makes sense will probably fall out during implementation.

• Reuse chrome’s hit testing code. Viz thread can send AggregatedHitTestRegion to UI thread, same as chrome.
  

• The real begin frame source continues to live on UI thread. UI blocks on viz, then viz sends out begin frames and blocks on clients (note this is begin frame in the synchronous compositor sense, ie viz does not expect a SubmitCompsitorFrame as a consequence; see deadline scheduler discussion below). Can optimize this as block UI until a single client returns has damage, or all clients returns no damage.

• Initially block waiting for all frames to match existing behavior. Can consider other policies if result is not ideal for performance.

[Bo Liu]

Hi all,

I've explored some options for splitting viz service to support webview's use case, and arrived at a different approach than previously stated in the doc.

* Use SkiaRenderer with SkDDL

* Do not "split" viz. Code that runs on chrome's viz thread will run on webview's viz thread. When SkiaRenderer schedules tasks on the "gpu" thread, it will be webview's render thread.

* Viz can only schedule gpu tasks on render thread when render thread is already blocked on viz thread and ready to accept gpu tasks. SkiaRenderer currently only needs to schedule tasks in construction, destruction, and DrawAndSwap, so it's not difficult to make this work. Will probably add checks to viz code that the scope of when SkiaRenderer needs to post to GPU does not expand.

I've written up this idea at the end the doc, along with other options I've explored. Folks who are familiar with viz and especially SkiaRenderer, PTAL and please comment if you see problems.

Thanks!

[Bo Liu]

Hi all,

Back again with more docs for you to review. Since last time, I've hacked together a working prototype. It proved that the ideas in the original design doc are feasible, and helped me have a better sense of what actually needs to be done.

The first doc is a list of tasks that needs to be done, broken down into milestones. Please comment if anything seems wrong. I will start working through them after I come back from vacation. But also feel free to pick up tasks from the list :p

Second doc (linked from first), is about delivering begin frames, which has had some changes since the original design doc. Again, please review and comment.

Thanks!