Notify WebWidget when its compositor surface is ready to use

Notify WebWidget when its compositor surface is ready to use

Before the browser UI thread has a chance to initialize the native window system
surface binding (which is different on each platform) any attempt to initialize
the compositor will fail in a way that appears fatal to WebKit. To avoid hitting
this, we set a bit when we receive an IPC sent by the browser UI thread after
it gets a chance to set up the native windowing stuff - RenderWidget::CompleteInit().
This bit delays RenderWidget-driven frame scheduling, but when WebKit is scheduling
frames (for example with the threaded compositor active) we also have to let
WebKit know so it can start rendering.

BUG=123356
TEST=See bug
TBR=darin


Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=133118

[jamesr, 2012-04-19 00:43:38]

See http://code.google.com/p/chromium/issues/detail?id=123356 and
https://bugs.webkit.org/show_bug.cgi?id=84305 for some background.

This patch has to land before https://bugs.webkit.org/show_bug.cgi?id=84305 can,
since it's an implementation of the newly added pure virtual WebWidget function.

[darin (slow to review), 2012-04-19 05:08:33]

would another approach be to make the "compositor surface" setup asynchronous? 
somehow Web{Widget,View}Client provides the "compositor surface" to WebKit.  it
must provide it synchronously today, but couldn't we change it to provide the
surface asynchronously?  then we could delay providing the surface until
CompleteInit is called, right?

is this all hidden behind WebViewClient::createGraphicsContext3D?  if we could
make that function complete asynchronously, would that do the trick?

https://chromiumcodereview.appspot.com/10095021/diff/1/content/renderer/rende...
File content/renderer/render_widget.cc (right):

https://chromiumcodereview.appspot.com/10095021/diff/1/content/renderer/rende...
content/renderer/render_widget.cc:191: webwidget_->setCompositorSurfaceReady();
nit: indentation

does it make sense to call compositor functions when not in composited mode? 
maybe this is all temporary anyways?

[jamesr, 2012-04-19 05:22:34]

On 2012/04/19 05:08:33, darin wrote:
> would another approach be to make the "compositor surface" setup asynchronous?

> somehow Web{Widget,View}Client provides the "compositor surface" to WebKit. 
it
> must provide it synchronously today, but couldn't we change it to provide the
> surface asynchronously?  then we could delay providing the surface until
> CompleteInit is called, right?

So the weird thing about all this is that we don't need a surface for any
reason, we just have to know that it exists somewhere.  Maybe the function name
is wrong.  We actually access the surface on the browser UI thread and never see
it (directly) in the render process.

> 
> is this all hidden behind WebViewClient::createGraphicsContext3D?  if we could
> make that function complete asynchronously, would that do the trick?

The tricky bit here is that if createGraphicsContext3D() fails (which it can if
we can't open a GPU channel at all, but it can't fail for any reasons specific
to this particular Widget) we want to fall back to software mode immediately. 
Maybe that could just fail fast in that case and defer returning a context until
the surface is ready.

> 
>
https://chromiumcodereview.appspot.com/10095021/diff/1/content/renderer/rende...
> File content/renderer/render_widget.cc (right):
> 
>
https://chromiumcodereview.appspot.com/10095021/diff/1/content/renderer/rende...
> content/renderer/render_widget.cc:191:
webwidget_->setCompositorSurfaceReady();
> nit: indentation
> 
> does it make sense to call compositor functions when not in composited mode? 
> maybe this is all temporary anyways?

I wish it were temporary :(.  The thing doing the frame scheduling is going to
need to know whether it can try to put a frame up or not.

[jamesr, 2012-04-19 05:23:50]

On 2012/04/19 05:08:33, darin wrote:
> would another approach be to make the "compositor surface" setup asynchronous?

> somehow Web{Widget,View}Client provides the "compositor surface" to WebKit. 
it
> must provide it synchronously today, but couldn't we change it to provide the
> surface asynchronously?  then we could delay providing the surface until
> CompleteInit is called, right?

Or do you mean that WebKit should poll for the surface instead of pushing it
from chrome -> WebKit?  I'm not sure how that would work.

[commit-bot: I haz the power, 2012-04-20 00:13:06]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/jamesr@chromium.org/10095021/1

[jamesr, 2012-04-20 00:14:09]

After our in-person discussion I'm going to continue with this for now and then
work on making the WebGraphicsContext3D providing logic be asynchronous (WebKit
will request a context via WebViewClient, chromium will later provide one via
WebView or WebWidget interface).  That'll require some changes across
WebViewImpl  and the compositor so it might take a bit more work and be much
scarier to merge to 19

[commit-bot: I haz the power, 2012-04-20 01:47:15]

Change committed as 133118

[darin (slow to review), 2012-04-23 16:47:54]

LGTM