Handle modified displays in mustash.

Handle modified displays in mustash.

Big CL that fixes many small things related to display information being
propagated when a display is modified. The primary change is that
ws::DisplayManager now handles OnDisplayModified() calls. This entails
the following steps:

1. The PlatformDisplay corresponding to the display is updated.
2. Mus sends an IPC to WM clients telling them the display has changed.
   This requires a new message in mojom::WindowManager and new method in
   WindowManagerDelegate.
3. Update the root ServerWindow for the display.
4. Mus sends an IPC to any other clients telling them the display has
   changed.

The ViewportMetrics class is moved from src/services/ui/ws/ to
src/services/ui/display so that it can be used in
PlatformScreenDelegate.

PlatformScreen now implements ui::DisplayController::StateController so
it can pick the display size.  A message is added to
mojom::TestDisplayController to trigger changing the display size. This
allows developers to try the functionality. An unused ash developer
keyboard shortcut is used to trigger changing the display size. This
shortcut is only temporary until settings are working.

Another small part of this change is the display insets are sent from
ash to PlatformScreen. This is tangentially related as it relies on
DisplayManager::OnDisplayModified() working.

BUG=641012
Committed: https://crrev.com/a06c6ea472e2ea1bf14fd34eb1092c7ef30bbdd4
Cr-Commit-Position: refs/heads/master@{#426830}

[kylechar, 2016-10-19 21:35:44]

[email protected] changed reviewers:
+ [email protected]

[kylechar, 2016-10-19 21:35:45]

+sky for everything except security review.

[sky, 2016-10-19 23:38:00]

https://codereview.chromium.org/2434923002/diff/20001/ash/mus/accelerators/ac...
File ash/mus/accelerators/accelerator_controller_delegate_mus.cc (right):

https://codereview.chromium.org/2434923002/diff/20001/ash/mus/accelerators/ac...
ash/mus/accelerators/accelerator_controller_delegate_mus.cc:107: //
TODO(kylechar): This is hack. I'm just stealing the shortcut key to
Please file a bug so we don't forget about it.

https://codereview.chromium.org/2434923002/diff/20001/ash/mus/root_window_con...
File ash/mus/root_window_controller.cc (right):

https://codereview.chromium.org/2434923002/diff/20001/ash/mus/root_window_con...
ash/mus/root_window_controller.cc:141: display::mojom::DisplayControllerPtr
display_controller;
Can you make WindowManager maintain a single connection to display_controller.
Otherwise we may end up with subtle ordering issues when a bunch of stuff
changes.

https://codereview.chromium.org/2434923002/diff/20001/ash/mus/window_manager.cc
File ash/mus/window_manager.cc (right):

https://codereview.chromium.org/2434923002/diff/20001/ash/mus/window_manager....
ash/mus/window_manager.cc:339: controller->set_display(display);
Can you make set_display() call to UpdateDisplay()? Otherwise it's easy to miss
the call to UpdateDisplay, and it's wierd that this code updates the displaylist
but RootWindowController::SetWorkAreaInests does it as well.

https://codereview.chromium.org/2434923002/diff/20001/services/ui/display/pla...
File services/ui/display/platform_screen_ozone.h (right):

https://codereview.chromium.org/2434923002/diff/20001/services/ui/display/pla...
services/ui/display/platform_screen_ozone.h:69: // Insets received from ash.
ash -> wm

https://codereview.chromium.org/2434923002/diff/20001/services/ui/display/pla...
services/ui/display/platform_screen_ozone.h:70: gfx::Insets last_insets;
It's a bit unclear what insets this is. How about last_work_area_insets?

https://codereview.chromium.org/2434923002/diff/20001/services/ui/display/pla...
services/ui/display/platform_screen_ozone.h:74: gfx::Size use_size;
requested_size?

https://codereview.chromium.org/2434923002/diff/20001/services/ui/display/vie...
File services/ui/display/viewport_metrics.h (right):

https://codereview.chromium.org/2434923002/diff/20001/services/ui/display/vie...
services/ui/display/viewport_metrics.h:17: return base::StringPrintf(
Please move this to viewport_metrics.cc

[kylechar, 2016-10-20 15:04:20]

https://codereview.chromium.org/2434923002/diff/20001/ash/mus/accelerators/ac...
File ash/mus/accelerators/accelerator_controller_delegate_mus.cc (right):

https://codereview.chromium.org/2434923002/diff/20001/ash/mus/accelerators/ac...
ash/mus/accelerators/accelerator_controller_delegate_mus.cc:107: //
TODO(kylechar): This is hack. I'm just stealing the shortcut key to
On 2016/10/19 23:37:59, sky wrote:
> Please file a bug so we don't forget about it.

Done.

https://codereview.chromium.org/2434923002/diff/20001/ash/mus/root_window_con...
File ash/mus/root_window_controller.cc (right):

https://codereview.chromium.org/2434923002/diff/20001/ash/mus/root_window_con...
ash/mus/root_window_controller.cc:141: display::mojom::DisplayControllerPtr
display_controller;
On 2016/10/19 23:37:59, sky wrote:
> Can you make WindowManager maintain a single connection to display_controller.
> Otherwise we may end up with subtle ordering issues when a bunch of stuff
> changes.

Done.

https://codereview.chromium.org/2434923002/diff/20001/ash/mus/window_manager.cc
File ash/mus/window_manager.cc (right):

https://codereview.chromium.org/2434923002/diff/20001/ash/mus/window_manager....
ash/mus/window_manager.cc:339: controller->set_display(display);
On 2016/10/19 23:37:59, sky wrote:
> Can you make set_display() call to UpdateDisplay()? Otherwise it's easy to
miss
> the call to UpdateDisplay, and it's wierd that this code updates the
displaylist
> but RootWindowController::SetWorkAreaInests does it as well.

I could do that. In general it seems wrong to me that
RootWindowController::display_ exists in the first place. Screen has a copy of
Display and the two copes need to be identical. So it's twice the memory and
more code to keep them in sync.

It seems like lots of mash_unittests rely on RootWindowController::display_
existing though. So maybe I could remove it in a followup CL?

https://codereview.chromium.org/2434923002/diff/20001/services/ui/display/pla...
File services/ui/display/platform_screen_ozone.h (right):

https://codereview.chromium.org/2434923002/diff/20001/services/ui/display/pla...
services/ui/display/platform_screen_ozone.h:69: // Insets received from ash.
On 2016/10/19 23:37:59, sky wrote:
> ash -> wm

Done.

https://codereview.chromium.org/2434923002/diff/20001/services/ui/display/pla...
services/ui/display/platform_screen_ozone.h:70: gfx::Insets last_insets;
On 2016/10/19 23:37:59, sky wrote:
> It's a bit unclear what insets this is. How about last_work_area_insets?

Done.

https://codereview.chromium.org/2434923002/diff/20001/services/ui/display/pla...
services/ui/display/platform_screen_ozone.h:74: gfx::Size use_size;
On 2016/10/19 23:37:59, sky wrote:
> requested_size?

Done.

https://codereview.chromium.org/2434923002/diff/20001/services/ui/display/vie...
File services/ui/display/viewport_metrics.h (right):

https://codereview.chromium.org/2434923002/diff/20001/services/ui/display/vie...
services/ui/display/viewport_metrics.h:17: return base::StringPrintf(
On 2016/10/19 23:37:59, sky wrote:
> Please move this to viewport_metrics.cc

Done.

[sky, 2016-10-20 15:33:25]

https://codereview.chromium.org/2434923002/diff/20001/ash/mus/window_manager.cc
File ash/mus/window_manager.cc (right):

https://codereview.chromium.org/2434923002/diff/20001/ash/mus/window_manager....
ash/mus/window_manager.cc:339: controller->set_display(display);
On 2016/10/20 15:04:19, kylechar wrote:
> On 2016/10/19 23:37:59, sky wrote:
> > Can you make set_display() call to UpdateDisplay()? Otherwise it's easy to
> miss
> > the call to UpdateDisplay, and it's wierd that this code updates the
> displaylist
> > but RootWindowController::SetWorkAreaInests does it as well.
> 
> I could do that. In general it seems wrong to me that
> RootWindowController::display_ exists in the first place. Screen has a copy of
> Display and the two copes need to be identical. So it's twice the memory and
> more code to keep them in sync.
> 
> It seems like lots of mash_unittests rely on RootWindowController::display_
> existing though. So maybe I could remove it in a followup CL?

Good point. I would still think RootWindowController should be the one updated
screen though as it does that in other places.

[kylechar, 2016-10-20 18:31:29]

https://codereview.chromium.org/2434923002/diff/20001/ash/mus/window_manager.cc
File ash/mus/window_manager.cc (right):

https://codereview.chromium.org/2434923002/diff/20001/ash/mus/window_manager....
ash/mus/window_manager.cc:339: controller->set_display(display);
On 2016/10/20 15:33:24, sky wrote:
> On 2016/10/20 15:04:19, kylechar wrote:
> > On 2016/10/19 23:37:59, sky wrote:
> > > Can you make set_display() call to UpdateDisplay()? Otherwise it's easy to
> > miss
> > > the call to UpdateDisplay, and it's wierd that this code updates the
> > displaylist
> > > but RootWindowController::SetWorkAreaInests does it as well.
> > 
> > I could do that. In general it seems wrong to me that
> > RootWindowController::display_ exists in the first place. Screen has a copy
of
> > Display and the two copes need to be identical. So it's twice the memory and
> > more code to keep them in sync.
> > 
> > It seems like lots of mash_unittests rely on RootWindowController::display_
> > existing though. So maybe I could remove it in a followup CL?
> 
> Good point. I would still think RootWindowController should be the one updated
> screen though as it does that in other places.

Done.

[sky, 2016-10-20 20:15:44]

LGTM

[kylechar, 2016-10-20 20:16:32]

[email protected] changed reviewers:
+ [email protected]

[kylechar, 2016-10-20 20:16:33]

Thanks sky!

+tsepez for *.mojom

[Tom Sepez, 2016-10-20 20:26:50]

mojom lgtm

[kylechar, 2016-10-20 20:49:37]

The CQ bit was checked by [email protected] to run a CQ dry run

[commit-bot: I haz the power, 2016-10-20 20:50:15]

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-10-20 21:25:21]

The CQ bit was unchecked by [email protected]

[commit-bot: I haz the power, 2016-10-20 21:25:22]

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

[kylechar, 2016-10-21 13:25:10]

The CQ bit was checked by [email protected] to run a CQ dry run

[commit-bot: I haz the power, 2016-10-21 13:25:21]

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-10-21 14:21:28]

The CQ bit was unchecked by [email protected]

[commit-bot: I haz the power, 2016-10-21 14:21:29]

Dry run: Try jobs failed on following builders:
  linux_chromium_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[kylechar, 2016-10-21 16:12:07]

The CQ bit was checked by [email protected]

[kylechar, 2016-10-21 16:12:07]

The patchset sent to the CQ was uploaded after l-g-t-m from [email protected],
[email protected]
Link to the patchset: https://codereview.chromium.org/2434923002/#ps120001
(title: "Fix PlatformScreenStub for tests.")

[commit-bot: I haz the power, 2016-10-21 16:12:35]

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-10-21 17:35:33]

Committed patchset #7 (id:120001)

[commit-bot: I haz the power, 2016-10-21 17:41:10]

Description was changed from

==========
Handle modified displays in mustash.

Big CL that fixes many small things related to display information being
propagated when a display is modified. The primary change is that
ws::DisplayManager now handles OnDisplayModified() calls. This entails
the following steps:

1. The PlatformDisplay corresponding to the display is updated.
2. Mus sends an IPC to WM clients telling them the display has changed.
   This requires a new message in mojom::WindowManager and new method in
   WindowManagerDelegate.
3. Update the root ServerWindow for the display.
4. Mus sends an IPC to any other clients telling them the display has
   changed.

The ViewportMetrics class is moved from src/services/ui/ws/ to
src/services/ui/display so that it can be used in
PlatformScreenDelegate.

PlatformScreen now implements ui::DisplayController::StateController so
it can pick the display size.  A message is added to
mojom::TestDisplayController to trigger changing the display size. This
allows developers to try the functionality. An unused ash developer
keyboard shortcut is used to trigger changing the display size. This
shortcut is only temporary until settings are working.

Another small part of this change is the display insets are sent from
ash to PlatformScreen. This is tangentially related as it relies on
DisplayManager::OnDisplayModified() working.

BUG=641012
==========

to

==========
Handle modified displays in mustash.

Big CL that fixes many small things related to display information being
propagated when a display is modified. The primary change is that
ws::DisplayManager now handles OnDisplayModified() calls. This entails
the following steps:

1. The PlatformDisplay corresponding to the display is updated.
2. Mus sends an IPC to WM clients telling them the display has changed.
   This requires a new message in mojom::WindowManager and new method in
   WindowManagerDelegate.
3. Update the root ServerWindow for the display.
4. Mus sends an IPC to any other clients telling them the display has
   changed.

The ViewportMetrics class is moved from src/services/ui/ws/ to
src/services/ui/display so that it can be used in
PlatformScreenDelegate.

PlatformScreen now implements ui::DisplayController::StateController so
it can pick the display size.  A message is added to
mojom::TestDisplayController to trigger changing the display size. This
allows developers to try the functionality. An unused ash developer
keyboard shortcut is used to trigger changing the display size. This
shortcut is only temporary until settings are working.

Another small part of this change is the display insets are sent from
ash to PlatformScreen. This is tangentially related as it relies on
DisplayManager::OnDisplayModified() working.

BUG=641012

Committed: https://crrev.com/a06c6ea472e2ea1bf14fd34eb1092c7ef30bbdd4
Cr-Commit-Position: refs/heads/master@{#426830}
==========

[commit-bot: I haz the power, 2016-10-21 17:41:11]

Patchset 7 (id:??) landed as
https://crrev.com/a06c6ea472e2ea1bf14fd34eb1092c7ef30bbdd4
Cr-Commit-Position: refs/heads/master@{#426830}