respect --force-compositing-mode for chrome: pages

Add a new flag to enable GPU compositing on chrome: pages

BUG=none
TEST=manual

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

[jamesr, 2011-07-28 00:06:38]

On ChromeOS the compositor startup time from cold start -> first frame up is
770ms, on top of the normal software paint time.  Are you OK with adding that to
the NTP display time?  They're thinking of making --force-compositing-mode the
default for chromeos in m14.

[Evan Stade, 2011-07-28 00:11:20]

On 2011/07/28 00:06:38, jamesr wrote:
> On ChromeOS the compositor startup time from cold start -> first frame up is
> 770ms, on top of the normal software paint time.  Are you OK with adding that
to
> the NTP display time?  They're thinking of making --force-compositing-mode the
> default for chromeos in m14.

I did not know this. I figured the flag was for debugging purposes only. How are
they doing it? by adding the flag at all times or by changing the circumstances
under which the web_prefs.force_compositing_mode flag is set? Because if it's
the latter, we could change the check in this patch to check the flag. My intent
is for this to only really affect debugging, and I'm sure we can easily sort out
how to have the GPU available for debugging the NTP without turning it on by
default before we're ready.

In the long term it would be ideal if the compositor could be warmed up while
the user is looking at the chromeos login screen.

[jamesr, 2011-07-28 00:13:17]

On 2011/07/28 00:11:20, Evan Stade wrote:
> On 2011/07/28 00:06:38, jamesr wrote:
> > On ChromeOS the compositor startup time from cold start -> first frame up is
> > 770ms, on top of the normal software paint time.  Are you OK with adding
that
> to
> > the NTP display time?  They're thinking of making --force-compositing-mode
the
> > default for chromeos in m14.
> 
> I did not know this. I figured the flag was for debugging purposes only. How
are
> they doing it? by adding the flag at all times or by changing the
circumstances
> under which the web_prefs.force_compositing_mode flag is set? Because if it's
> the latter, we could change the check in this patch to check the flag. My
intent
> is for this to only really affect debugging, and I'm sure we can easily sort
out
> how to have the GPU available for debugging the NTP without turning it on by
> default before we're ready.

I believe it's by the former, through a launcher script.  I'm not 100% sure
about that.

> 
> In the long term it would be ideal if the compositor could be warmed up while
> the user is looking at the chromeos login screen.

Yes, and ideally we'd warm up the compositor infrastructure for desktop chrome
earlier in the process as well.  Currently we don't do that, though, so I'm
hesitant to add this behavior before we get a chance to optimize it a bit.

[Evan Stade, 2011-07-28 00:37:57]

On 2011/07/28 00:13:17, jamesr wrote:
> On 2011/07/28 00:11:20, Evan Stade wrote:
> > On 2011/07/28 00:06:38, jamesr wrote:
> > > On ChromeOS the compositor startup time from cold start -> first frame up
is
> > > 770ms, on top of the normal software paint time.  Are you OK with adding
> that
> > to
> > > the NTP display time?  They're thinking of making --force-compositing-mode
> the
> > > default for chromeos in m14.
> > 
> > I did not know this. I figured the flag was for debugging purposes only. How
> are
> > they doing it? by adding the flag at all times or by changing the
> circumstances
> > under which the web_prefs.force_compositing_mode flag is set? Because if
it's
> > the latter, we could change the check in this patch to check the flag. My
> intent
> > is for this to only really affect debugging, and I'm sure we can easily sort
> out
> > how to have the GPU available for debugging the NTP without turning it on by
> > default before we're ready.
> 
> I believe it's by the former, through a launcher script.  I'm not 100% sure
> about that.

who should I email? I think this patch is correct, or can be made to be correct,
assuming they are aware of it over on the chromeos side. (Also note that the m14
branch has already been cut so this won't affect m14)

> 
> > 
> > In the long term it would be ideal if the compositor could be warmed up
while
> > the user is looking at the chromeos login screen.
> 
> Yes, and ideally we'd warm up the compositor infrastructure for desktop chrome
> earlier in the process as well.  Currently we don't do that, though, so I'm
> hesitant to add this behavior before we get a chance to optimize it a bit.

[jamesr1, 2011-07-28 00:43:03]

I think Zelidrag would be the place to start.

On Wed, Jul 27, 2011 at 5:37 PM, <estade@chromium.org> wrote:

> On 2011/07/28 00:13:17, jamesr wrote:
>
>> On 2011/07/28 00:11:20, Evan Stade wrote:
>> > On 2011/07/28 00:06:38, jamesr wrote:
>> > > On ChromeOS the compositor startup time from cold start -> first frame
>> up
>>
> is
>
>> > > 770ms, on top of the normal software paint time.  Are you OK with
>> adding
>> that
>> > to
>> > > the NTP display time?  They're thinking of making
>> --force-compositing-mode
>> the
>> > > default for chromeos in m14.
>> >
>> > I did not know this. I figured the flag was for debugging purposes only.
>> How
>> are
>> > they doing it? by adding the flag at all times or by changing the
>> circumstances
>> > under which the web_prefs.force_compositing_**mode flag is set? Because
>> if
>>
> it's
>
>> > the latter, we could change the check in this patch to check the flag.
>> My
>> intent
>> > is for this to only really affect debugging, and I'm sure we can easily
>> sort
>> out
>> > how to have the GPU available for debugging the NTP without turning it
>> on by
>> > default before we're ready.
>>
>
>  I believe it's by the former, through a launcher script.  I'm not 100%
>> sure
>> about that.
>>
>
> who should I email? I think this patch is correct, or can be made to be
> correct,
> assuming they are aware of it over on the chromeos side. (Also note that
> the m14
> branch has already been cut so this won't affect m14)
>
>
>
>  >
>> > In the long term it would be ideal if the compositor could be warmed up
>>
> while
>
>> > the user is looking at the chromeos login screen.
>>
>
>  Yes, and ideally we'd warm up the compositor infrastructure for desktop
>> chrome
>> earlier in the process as well.  Currently we don't do that, though, so
>> I'm
>> hesitant to add this behavior before we get a chance to optimize it a bit.
>>
>
>
>
>
http://codereview.chromium.**org/7519017/<http://codereview.chromium.org/7519...
>

[Evan Stade, 2011-07-28 02:16:11]

OK, I've changed it to use a new flag that won't affect any upcoming release

[Evan Stade, 2011-07-28 23:03:44]

ping

[jamesr, 2011-07-28 23:06:59]

lgtm, although i'm not an OWNER for anything interesting

[darin (slow to review), 2011-07-28 23:09:26]

LGTM

[darin (slow to review), 2011-07-28 23:10:02]

please update the change description, and maybe you should consider adding an
option to about:flags.

[Evan Stade, 2011-07-28 23:14:06]

description updated. I think for now it's just a tool for debugging or
benchmarking so we don't need an about:flags entry. If you want to start
dogfooding it I will add one.

[darin (slow to review), 2011-07-28 23:31:53]

I'm not sure how to enable it on ChromeOS unless it is in about:flags.

-Darin

On Thu, Jul 28, 2011 at 4:14 PM, <estade@chromium.org> wrote:

> description updated. I think for now it's just a tool for debugging or
> benchmarking so we don't need an about:flags entry. If you want to start
> dogfooding it I will add one.
>
>
>
http://codereview.chromium.**org/7519017/<http://codereview.chromium.org/7519...
>

[Evan Stade, 2011-08-01 19:24:30]

zel wants to add it by default for chromeos. If it is on my default, there will
be no use for an about:flag, so I'll let him sort that out and if the decision
is not to turn it on by default yet, I'll come back and add the about:flag.

[darin (slow to review), 2011-08-01 19:45:52]

OK

On Mon, Aug 1, 2011 at 12:24 PM, <estade@chromium.org> wrote:

> zel wants to add it by default for chromeos. If it is on my default, there
> will
> be no use for an about:flag, so I'll let him sort that out and if the
> decision
> is not to turn it on by default yet, I'll come back and add the about:flag.
>
>
>
http://codereview.chromium.**org/7519017/<http://codereview.chromium.org/7519...
>