Hmm ok WebView is a bit different from Chrome in that regard, since in Chrome we'd more likely have different render processes for simultaneously visible things (OOPIF or multiple browser windows).

With unified BeginFrames the point is though to move the decision logic up to one place in the browser. And consolidating them is maybe not all that compatible with how we plumbed things through RWHV now.

Maybe WebView needs its own BeginFrame plumbing if you really want this optimization.

Yeah, this means webview can't reuse BeginFrame plumbing in RWHVA.

Multiple webviews is more similar to multiple windows than OOPIF.

For multiple renderer processes, I was daydreaming about sending them in parallel, and blocking for all the replies, which kinda requires inventing a new way to do sync IPC.

That's really unfortunate to not be able to reuse BeginFrame plumbing and it will definitely be at odds with how every other platform will work.  Do you have any more docs or information about how you want this to work?

No docs.. I just had this thought last friday when looking at a trace from inbox.

Basically, begin frame IPC in sync compositor is synchronous, so blocks on the UI thread and has pretty high overhead. And this is just one idea for reducing the number of sync IPCs per frame.

Other than using a sync IPC, webview begin frame is the same as chrome.


Actually, maybe re-using RWHVA is possible: In the regular "BeginFrame" call, webview just registers that a sync compositor needs BeginFrame for this frame. Then if there is a separate call at the end of vsync to say "all begin frames have been called", then sync compositor can use that as a flush and send only a single IPC.

Hmm, that actually sounds better..

> Basically, begin frame IPC in sync compositor is synchronous, so blocks on the UI thread

why does BeginFrame block?

We could also see how this behaves with Mojo which doesn't need to bounce to the sender IO thread.

> why does BeginFrame block?

Any scroll from compositor for that frame must be synchronized back to the UI thread in vsync. Otherwise, the gmail behavior where gmail scrolls other native views to the webview scroll offset breaks.

Has a CL: https://codereview.chromium.org/2160743002/

Still going to share BeginFrame implementation as chrome. This bug only refers to the webview-only *synchronous* IPC that's sent after chrome's async begin frame IPC.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/3dd3ca72f1a2c3211177c72aae2d5027d8217769

commit 3dd3ca72f1a2c3211177c72aae2d5027d8217769
Author: boliu <boliu@chromium.org>
Date: Fri Jul 29 00:18:37 2016

sync compositor: Reduce begin frame sync IPC overhead

By making the begin frame sync IPC per renderer process rather than
per compositor.

Convert SyncCompositorMsg_SynchronizeRendererState
to a control message, with a list of routing_ids as input, and a list of
SyncCompositorCommonRendererParams as output.

Introduce SynchronousCompositorRPHObserver which is tied to the
lifetime of the RenderProcessHost, which is the browser side handler of
control messages. SynchronousCompositorFilter serves as the renderer
side control message handler.

SynchronousCompositorRPHObserver adds itself as a vsync observer
for the duration of a single vsync. Then its OnVSync callback is called
after SynchronousCompositorHosts, where the single synchronous
IPC is sent.

BUG= 596235 

Review-Url: https://codereview.chromium.org/2160743002
Cr-Commit-Position: refs/heads/master@{#408528}

[modify] https://crrev.com/3dd3ca72f1a2c3211177c72aae2d5027d8217769/content/browser/android/synchronous_compositor_host.cc
[modify] https://crrev.com/3dd3ca72f1a2c3211177c72aae2d5027d8217769/content/browser/android/synchronous_compositor_host.h
[add] https://crrev.com/3dd3ca72f1a2c3211177c72aae2d5027d8217769/content/browser/android/synchronous_compositor_observer.cc
[add] https://crrev.com/3dd3ca72f1a2c3211177c72aae2d5027d8217769/content/browser/android/synchronous_compositor_observer.h
[modify] https://crrev.com/3dd3ca72f1a2c3211177c72aae2d5027d8217769/content/browser/bad_message.h
[modify] https://crrev.com/3dd3ca72f1a2c3211177c72aae2d5027d8217769/content/browser/renderer_host/render_widget_host_view_android.cc
[modify] https://crrev.com/3dd3ca72f1a2c3211177c72aae2d5027d8217769/content/common/android/sync_compositor_messages.cc
[modify] https://crrev.com/3dd3ca72f1a2c3211177c72aae2d5027d8217769/content/common/android/sync_compositor_messages.h
[modify] https://crrev.com/3dd3ca72f1a2c3211177c72aae2d5027d8217769/content/content_browser.gypi
[modify] https://crrev.com/3dd3ca72f1a2c3211177c72aae2d5027d8217769/content/renderer/android/synchronous_compositor_filter.cc
[modify] https://crrev.com/3dd3ca72f1a2c3211177c72aae2d5027d8217769/content/renderer/android/synchronous_compositor_filter.h
[modify] https://crrev.com/3dd3ca72f1a2c3211177c72aae2d5027d8217769/content/renderer/android/synchronous_compositor_proxy.cc
[modify] https://crrev.com/3dd3ca72f1a2c3211177c72aae2d5027d8217769/content/renderer/android/synchronous_compositor_proxy.h