Turning the threaded compositor into a runtime option. This CL

Turning the threaded compositor into a runtime option. This CL
must land after https://bugs.webkit.org/show_bug.cgi?id=69391

BUG=none
TEST=Covered by existing compositor tests
Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=104542

[vangelis, 2011-10-05 06:11:42]

James, the render_view is one level up in the hierarchy so it wasn't obvious how
to access the webkit settings directly from render_widget as you suggested. 

I ended up implementing this via the WebWidgetClient interface but I'd be happy
to change it if there's a better way that doesn't need a staged commit.

[jamesr, 2011-10-05 18:38:37]

On 2011/10/05 06:11:42, vangelis wrote:
> James, the render_view is one level up in the hierarchy so it wasn't obvious
how
> to access the webkit settings directly from render_widget as you suggested. 
> 
> I ended up implementing this via the WebWidgetClient interface but I'd be
happy
> to change it if there's a better way that doesn't need a staged commit.

What I meant was this: The bit you're looking for is on the WebSettings
associated with the WebView. Every render_widget is associated with a WebWidget,
and every render_view (which is a subclass of render_widget) is associated with
a WebView (which is a subclass of WebWidget).  WebViews have WebSettings.  Since
the threaded compositing path is already in WebSettings what you could do is
add:

virtual bool widgetHandlesScheduling() const { return false; }

to render_widget and then have

virtual bool widgetHandlesScheduling() const { return
webview()->settings()->useThreadedCompositing(); }

on render_view

I'm sure you can think of better names.  That way, you don't have to duplicate
this bit across multiple places or worry about different systems getting out of
sync.

[vangelis, 2011-10-05 20:13:41]

On 2011/10/05 18:38:37, jamesr wrote:
> On 2011/10/05 06:11:42, vangelis wrote:
> > James, the render_view is one level up in the hierarchy so it wasn't obvious
> how
> > to access the webkit settings directly from render_widget as you suggested. 
> > 
> > I ended up implementing this via the WebWidgetClient interface but I'd be
> happy
> > to change it if there's a better way that doesn't need a staged commit.
> 
> What I meant was this: The bit you're looking for is on the WebSettings
> associated with the WebView. Every render_widget is associated with a
WebWidget,
> and every render_view (which is a subclass of render_widget) is associated
with
> a WebView (which is a subclass of WebWidget).  WebViews have WebSettings. 
Since
> the threaded compositing path is already in WebSettings what you could do is
> add:
> 
> virtual bool widgetHandlesScheduling() const { return false; }
> 
> to render_widget and then have
> 
> virtual bool widgetHandlesScheduling() const { return
> webview()->settings()->useThreadedCompositing(); }
> 
> on render_view
> 
> I'm sure you can think of better names.  That way, you don't have to duplicate
> this bit across multiple places or worry about different systems getting out
of
> sync.

Doh, of course :)

Thanks, I updated the patch.

[jamesr, 2011-10-05 20:16:51]

I think you forgot to upload the render_view changes.  Otherwise, though, this
lgtm.

[vangelis, 2011-10-05 20:25:57]

On 2011/10/05 20:16:51, jamesr wrote:
> I think you forgot to upload the render_view changes.  Otherwise, though, this
> lgtm.

Oopp, sorry about that.  Uploaded render_view changes.

[jamesr, 2011-10-05 20:36:08]

LGTM - tryjobs please before landing, to be safe :)

[jamesr, 2011-10-06 01:09:17]

On 2011/10/05 20:36:08, jamesr wrote:
> LGTM - tryjobs please before landing, to be safe :)

FYI I hooked this up to a command line switch here:
http://codereview.chromium.org/8163008/ so I can keep debugging locally.