summary from meeting. we can do this in "stages"

* first, add code path to deliver sub frame compositor frames to the display compositor. there is no need for any of the "synchronous compositing" things for subframes. this has no surface synchronization, which means there is going to be artifacts for cases like resize which causes iframe to resize. incidentally, this is how chrome works at the moment as well

* add surface synchronization. this requires splitting the "surface aggregation" logic from the composition logic in display compositor, so they can live on separate threads. webview will need to do the aggregation part on the UI thread to avoid unnecessarily invalidating just for updating a frame. however this probably negates some optimizations we have right now (async draw), and we should try to avoid that if at all possible

* software draw is probably going to need a real software display compositor on the UI thread now, but still depends on the aggregation and composite split. UI will just work out what subframe is still needed, and then synchronously get those subframes. performance is definitely going to be out of the window. oh well.

so this is sounding like a year-long project now to do everything here.

Cool! Thanks for the summary, Bo! I'm adding a bunch of people here in CC as an FYI.

Issue 806404 has been merged into this issue.

adding to the "rendering" bug.

hit testing (ie, figuring out which renderer to send input events to, implemented in RenderWidgetHostInputEventRouter::FindViewAtLocation) totally doesn't work with webview either right now.

+kbr@

Android WebView does not currently support site isolation, video in surfaces or offscreen canvas. Code structure has also diverged with the Viz OOP-D (out of process display compositor) architecture.

We should try to unify code structure and this project blocks some of our 2019 graphics plans for offscreen canvas.

Setting to P1 and targeting M74 (Branch March 7, 2019, Stable April 23, 2019).

Taking ownership.

This comment from August 1st outlines the design here, and probably should have been better on this bug: https://bugs.chromium.org/p/chromium/issues/detail?id=806404#c12

"""
fsamuel and I spent 1.5hrs in front a whiteboard brainstorming potential approaches. I'm dumping things in my head, which may not make a lot of sense to others.

Draw constraints (ie the matrix in kModeDraw) need to be propagated to all sub frames. So viewport_for_tile_priority will need to be an additional visual property synced to all sub frames, and a root matrix. This is currently a very small bit of code on the compositor thread, but with oopif, it's a lot more complicated. May not be necessary for other uses cases like offscreen canvas or video though.

We'll probably have a new "viz" thread. Split the current viz::Display into 3 parts:

* begin frame source on the UI thread. This should already be pretty independent. Surface clients send needs begin frame requests to it, and it dispatches begin frame signals, and is responsible for synchronously and efficiently getting the results back to UI thread, and use that to decide whether to invalidate webview. We can use the same IPC tricks today, hopefully shouldn't be too bad.

* surface aggregation on the new viz thread. CompositorFrames are submitted on this thread whenever they arrive from renderer. Android render thread can block on this thread, eg waiting for a particular main frame to arrive. (IO thread currently serves this purpose today, but surface aggregation is somewhat expensive, so probably not very suitable for IO thread) The reason this cannot be on the UI thread is that we want the ability to submit frames at any point.

* DrawAndSwap part on android render thread. This is the part that talks to command buffer client. There needs to be some kind of efficient synchronization with the aggregation part, which I don't really fully understand.

Ideally we wouldn't want to split the surface aggregation and DrawAndSwap part, but DrawAndSwap (command buffer client) which may block on the render thread (command buffer service), which then introduces a circular wait. But I'll have to think about this in more detail if this can be avoided..

We can decide on policy of when main frame arrives, but subframes have not. This is the latency vs efficiency vs throughput trade off.

Input routing is already solved problem for oop-d. We just need to reuse the same code by sending hittesting data from the surface aggregation part back to the UI thread.


Doesn't feel all that bad in my head right now :p
"""

After chatting with kbr@, we decided targeting M73 makes more sense.

I'm not actively working on this so I'm passing along to boliu@