Remove CreateDefaultDisplay().

Remove CreateDefaultDisplay().

Initializing displays after first WM connection seems unnecessary. This
is especially true on Chrome OS devices where there is a significant
delay to query display hardware.

Immediately start display initialization after ui::Service starts. The
timing of this step isn't deterministic anyways. Tests that rely on
displays being created already make a method call to set the number of
displays. Change this call to actually create ws::Display objects
instead.

BUG=663907
Committed: https://crrev.com/526be5ac7017cdb08fcaba441125b2a3aaec3d92
Cr-Commit-Position: refs/heads/master@{#431677}

[kylechar, 2016-11-10 18:05:58]

Patchset #2 (id:20001) has been deleted

[kylechar, 2016-11-10 18:08:02]

The CQ bit was checked by kylechar@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-11-10 18:08:25]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[kylechar, 2016-11-10 18:43:24]

kylechar@chromium.org changed reviewers:
+ sky@chromium.org

[commit-bot: I haz the power, 2016-11-10 18:51:40]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-11-10 18:51:41]

Dry run: This issue passed the CQ dry run.

[sky, 2016-11-10 23:48:17]

The reason to wait for the WM is that clients need the non-client frame values
that the window manager provides before they can do anything. Does this change
alter that?

[kylechar, 2016-11-11 19:56:03]

On 2016/11/10 23:48:17, sky wrote:
> The reason to wait for the WM is that clients need the non-client frame values
> that the window manager provides before they can do anything. Does this change
> alter that?

I don't think so. UserDisplayManager is what sends display information to the
clients. If a observer connects before
UserDisplayManager::OnFrameDecorationValuesChanged() has been called then
nothing happens, later when OnFrameDecorationValuesChanged() gets called all
observers then get an IPC with the current display state. If an observer
connects after OnFrameDecorationValuesChanged() was called then it immediately
gets an IPC with the current display state. So UserDisplayManager handles that
case.

I don't see any other obvious problems with the timing of getting displays vs
having a fully connect WM. Testing locally it doesn't seem to make a difference
which comes first. There is a lot of complex ordering during startup though...
so it's really tough to say.

[sky, 2016-11-11 21:19:56]

Thanks for looking LGTM

[kylechar, 2016-11-11 21:31:07]

The CQ bit was checked by kylechar@chromium.org

[commit-bot: I haz the power, 2016-11-11 21:32:13]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-11-11 23:11:58]

Committed patchset #2 (id:40001)

[commit-bot: I haz the power, 2016-11-11 23:54:18]

Description was changed from

==========
Remove CreateDefaultDisplay().

Initializing displays after first WM connection seems unnecessary. This
is especially true on Chrome OS devices where there is a significant
delay to query display hardware.

Immediately start display initialization after ui::Service starts. The
timing of this step isn't deterministic anyways. Tests that rely on
displays being created already make a method call to set the number of
displays. Change this call to actually create ws::Display objects
instead.

BUG=663907
==========

to

==========
Remove CreateDefaultDisplay().

Initializing displays after first WM connection seems unnecessary. This
is especially true on Chrome OS devices where there is a significant
delay to query display hardware.

Immediately start display initialization after ui::Service starts. The
timing of this step isn't deterministic anyways. Tests that rely on
displays being created already make a method call to set the number of
displays. Change this call to actually create ws::Display objects
instead.

BUG=663907

Committed: https://crrev.com/526be5ac7017cdb08fcaba441125b2a3aaec3d92
Cr-Commit-Position: refs/heads/master@{#431677}
==========

[commit-bot: I haz the power, 2016-11-11 23:54:18]

Patchset 2 (id:??) landed as
https://crrev.com/526be5ac7017cdb08fcaba441125b2a3aaec3d92
Cr-Commit-Position: refs/heads/master@{#431677}