Turn on GPU rasterization when --enable-bleeding-edge-rendering-fast-paths is true.

Turn on GPU rasterization when --enable-bleeding-edge-rendering-fast-paths is true.

BUG=

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=255155

[jamesr, 2014-02-22 00:30:04]

not lgtm

https://codereview.chromium.org/168183004/diff/1/cc/base/switches.cc
File cc/base/switches.cc (right):

https://codereview.chromium.org/168183004/diff/1/cc/base/switches.cc#newcode37
cc/base/switches.cc:37: //  content/public/common/content_switches.cc.
no.  if you want the behavior controlled by a content::, set it from content
code. you probably want content/renderer/gpu/render_widget_compositor.cc to set
the appropriate setting or, failing that, populate the appropriate flag for
render process's command line in render_process_host_impl

[chrishtr, 2014-02-22 00:33:11]

https://codereview.chromium.org/168183004/diff/1/cc/base/switches.cc
File cc/base/switches.cc (right):

https://codereview.chromium.org/168183004/diff/1/cc/base/switches.cc#newcode37
cc/base/switches.cc:37: //  content/public/common/content_switches.cc.
On 2014/02/22 00:30:04, jamesr wrote:
> no.  if you want the behavior controlled by a content::, set it from content
> code. you probably want content/renderer/gpu/render_widget_compositor.cc to
set
> the appropriate setting or, failing that, populate the appropriate flag for
> render process's command line in render_process_host_impl

Ok, I  can do that, thanks for the pointer.

I don't understand these dependencies though. Why can
content/renderer/gpu/render_widget_compositor.cc see a content switch and also
this file, but not vice versa?

[jamesr, 2014-02-22 00:34:08]

On 2014/02/22 00:33:11, Chris Harrelson wrote:
> https://codereview.chromium.org/168183004/diff/1/cc/base/switches.cc
> File cc/base/switches.cc (right):
> 
> https://codereview.chromium.org/168183004/diff/1/cc/base/switches.cc#newcode37
> cc/base/switches.cc:37: //  content/public/common/content_switches.cc.
> On 2014/02/22 00:30:04, jamesr wrote:
> > no.  if you want the behavior controlled by a content::, set it from content
> > code. you probably want content/renderer/gpu/render_widget_compositor.cc to
> set
> > the appropriate setting or, failing that, populate the appropriate flag for
> > render process's command line in render_process_host_impl
> 
> Ok, I  can do that, thanks for the pointer.
> 
> I don't understand these dependencies though. Why can
> content/renderer/gpu/render_widget_compositor.cc see a content switch and also
> this file, but not vice versa?

The DEPS rules in various directories list the rules.  A dependency graph should
be a DAG which means that there are one-way dependencies.  cc/ is a library used
by many parts of the code, not just content.

[chrishtr, 2014-02-22 00:38:28]

Updated.

[chrishtr, 2014-02-22 00:38:42]

https://codereview.chromium.org/168183004/diff/1/cc/base/switches.cc
File cc/base/switches.cc (right):

https://codereview.chromium.org/168183004/diff/1/cc/base/switches.cc#newcode37
cc/base/switches.cc:37: //  content/public/common/content_switches.cc.
On 2014/02/22 00:33:11, Chris Harrelson wrote:
> On 2014/02/22 00:30:04, jamesr wrote:
> > no.  if you want the behavior controlled by a content::, set it from content
> > code. you probably want content/renderer/gpu/render_widget_compositor.cc to
> set
> > the appropriate setting or, failing that, populate the appropriate flag for
> > render process's command line in render_process_host_impl
> 
> Ok, I  can do that, thanks for the pointer.
> 
> I don't understand these dependencies though. Why can
> content/renderer/gpu/render_widget_compositor.cc see a content switch and also
> this file, but not vice versa?

Done.

[jamesr, 2014-02-22 00:46:24]

this is implemented correctly, so lgtm to reverse my earlier n-o-t, but I'm not
really convinced this is a good idea.  I'll leave that up to the silk folks to
decide.

[enne (OOO), 2014-02-22 00:48:41]

+nduca, ernstm

[nduca, 2014-02-24 20:15:06]

im fine with this, but it should also imply impl side painting i think. lgtm
assuming enne too

[chrishtr, 2014-03-05 17:42:49]

The CQ bit was checked by chrishtr@chromium.org

[commit-bot: I haz the power, 2014-03-05 17:44:04]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/chrishtr@chromium.org/168183004/70001

[commit-bot: I haz the power, 2014-03-05 21:49:43]

Change committed as 255155