Fix ws::Display initialization order.

Fix ws::Display initialization order.

The initialization order for ws::Display was a bit mixed up. It was not
waiting for the accelerated widget to be available, assuming that it was
available immediately after calling PlatformDisplay::Init() instead.

Reorder ws::Display and ws::PlatformDisplay Init() methods. Make sure
that most work is done in the Init() methods instead of constructors, as
PlatformWindowDelegate::OnAcceleratedWidgetAvailable() can happen
synchronously when creating the PlatformWindow, and we want constructors
to have finished before we start using the objects.

BUG=663907
Committed: https://crrev.com/1df004a488492aa7938dac963ddc5f6fc28f5ce7
Cr-Commit-Position: refs/heads/master@{#432616}

[kylechar, 2016-11-14 18:26:02]

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

[sky, 2016-11-14 21:36:19]

https://codereview.chromium.org/2497303002/diff/20001/services/ui/ws/display.h
File services/ui/ws/display.h (right):

https://codereview.chromium.org/2497303002/diff/20001/services/ui/ws/display....
services/ui/ws/display.h:79: gfx::Size GetPixelSize() const;
Isn't mus going to be entirely pixels? If so, it doesn't seem we need to be
explicit here.

[kylechar, 2016-11-14 21:39:52]

On 2016/11/14 21:36:19, sky wrote:
> https://codereview.chromium.org/2497303002/diff/20001/services/ui/ws/display.h
> File services/ui/ws/display.h (right):
> 
>
https://codereview.chromium.org/2497303002/diff/20001/services/ui/ws/display....
> services/ui/ws/display.h:79: gfx::Size GetPixelSize() const;
> Isn't mus going to be entirely pixels? If so, it doesn't seem we need to be
> explicit here.

Is it going to be? Right now for event targeting on multiple display we're using
some DIP coordinates (which doesn't work correctly, see crbug.com/660398, but
regardless). I'd imagine DIP is also necessary to compute cursor movement
between displays.

[sky, 2016-11-14 22:20:40]

On 2016/11/14 21:39:52, kylechar wrote:
> On 2016/11/14 21:36:19, sky wrote:
> >
https://codereview.chromium.org/2497303002/diff/20001/services/ui/ws/display.h
> > File services/ui/ws/display.h (right):
> > 
> >
>
https://codereview.chromium.org/2497303002/diff/20001/services/ui/ws/display....
> > services/ui/ws/display.h:79: gfx::Size GetPixelSize() const;
> > Isn't mus going to be entirely pixels? If so, it doesn't seem we need to be
> > explicit here.
> 
> Is it going to be?

It should be. In the long term we may offer up both coordinates (dip and
pixels), but in the near term mus-ws is all pixels. Feel free to talk with
Sadrul about this.


> Right now for event targeting on multiple display we're using
> some DIP coordinates (which doesn't work correctly, see crbug.com/660398, but
> regardless). I'd imagine DIP is also necessary to compute cursor movement
> between displays.

I'm not sure of the specifics, but internally everything in mus should be
pixels.

[kylechar, 2016-11-16 14:29:52]

https://codereview.chromium.org/2497303002/diff/20001/services/ui/ws/display.h
File services/ui/ws/display.h (right):

https://codereview.chromium.org/2497303002/diff/20001/services/ui/ws/display....
services/ui/ws/display.h:79: gfx::Size GetPixelSize() const;
On 2016/11/14 21:36:19, sky wrote:
> Isn't mus going to be entirely pixels? If so, it doesn't seem we need to be
> explicit here.

Changed the name back and added a comment. Will write up something more detailed
after a discussion with sadrul.

[sky, 2016-11-16 16:57:34]

LGTM

[kylechar, 2016-11-16 16:57:57]

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

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

Dry run: 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-16 18:45:48]

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

[commit-bot: I haz the power, 2016-11-16 18:45:49]

Dry run: Try jobs failed on following builders:
  win_chromium_x64_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_x64_...)

[kylechar, 2016-11-16 19:27:52]

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

[commit-bot: I haz the power, 2016-11-16 19:28:48]

Dry run: 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-16 20:35:50]

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

[commit-bot: I haz the power, 2016-11-16 20:35:50]

Dry run: This issue passed the CQ dry run.

[kylechar, 2016-11-16 20:36:09]

The CQ bit was checked by kylechar@chromium.org

[kylechar, 2016-11-16 20:36:09]

The patchset sent to the CQ was uploaded after l-g-t-m from sky@chromium.org
Link to the patchset: https://codereview.chromium.org/2497303002/#ps60001
(title: "Fix use after move in test.")

[commit-bot: I haz the power, 2016-11-16 20:36:56]

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-16 20:44:00]

Committed patchset #4 (id:60001)

[commit-bot: I haz the power, 2016-11-16 20:55:28]

Description was changed from

==========
Fix ws::Display initialization order.

The initialization order for ws::Display was a bit mixed up. It was not
waiting for the accelerated widget to be available, assuming that it was
available immediately after calling PlatformDisplay::Init() instead.

Reorder ws::Display and ws::PlatformDisplay Init() methods. Make sure
that most work is done in the Init() methods instead of constructors, as
PlatformWindowDelegate::OnAcceleratedWidgetAvailable() can happen
synchronously when creating the PlatformWindow, and we want constructors
to have finished before we start using the objects.

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

to

==========
Fix ws::Display initialization order.

The initialization order for ws::Display was a bit mixed up. It was not
waiting for the accelerated widget to be available, assuming that it was
available immediately after calling PlatformDisplay::Init() instead.

Reorder ws::Display and ws::PlatformDisplay Init() methods. Make sure
that most work is done in the Init() methods instead of constructors, as
PlatformWindowDelegate::OnAcceleratedWidgetAvailable() can happen
synchronously when creating the PlatformWindow, and we want constructors
to have finished before we start using the objects.

BUG=663907

Committed: https://crrev.com/1df004a488492aa7938dac963ddc5f6fc28f5ce7
Cr-Commit-Position: refs/heads/master@{#432616}
==========

[commit-bot: I haz the power, 2016-11-16 20:55:29]

Patchset 4 (id:??) landed as
https://crrev.com/1df004a488492aa7938dac963ddc5f6fc28f5ce7
Cr-Commit-Position: refs/heads/master@{#432616}