Pass device scale factor from display to ws.

Pass device scale factor from display to ws in mustash.

Pass extra info from PlatfromScreen to it's delegate so that the device
bounds in DIP, the pixel size and device scale factor are available. The
the delegate happens to be the WS and it will use this information to
support high-DPI displays.

Most of the changes inside PlatformScreenOzone are throw away.
ash::DisplayManager already has this logic. We still have to finish
separating ash::DisplayManager from the rest of ash though,
necessitating a bit of code duplication until then.

The bounds of the display are in DIP. This is the format that is
expected from clients that receive the bounds via ScreenMus. The pixel
size of the display is needed for creating the PlatformWindow.

With this change mustash should run in high-DPI mode when running on a
device with a high-DPI internal display. It can also be enabled by
specifying the DPI for the fake display in Ozone X11, for example
--screen-config=800x800^300 will be high-DPI.

BUG=649008
Committed: https://crrev.com/d768e9a95f246bbe36f72244fdc6be15dcc99387
Cr-Commit-Position: refs/heads/master@{#420757}

[kylechar, 2016-09-20 20:58:22]

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

[kylechar, 2016-09-20 20:58:23]

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

[kylechar, 2016-09-20 20:58:23]

rjkroege: Let me know what you think of these changes? The stuff outside
services/ui/* will be removed from the CL (it's there so I can run it locally
without crashing).

[kylechar, 2016-09-20 20:58:23]

rjkroege: Let me know what you think of these changes? The stuff outside
services/ui/* will be removed from the CL (it's there so I can run it locally
without crashing).

[rjkroege, 2016-09-21 13:23:47]

https://codereview.chromium.org/2356913002/diff/1/services/ui/display/platfor...
File services/ui/display/platform_screen_delegate.h (right):

https://codereview.chromium.org/2356913002/diff/1/services/ui/display/platfor...
services/ui/display/platform_screen_delegate.h:26: const gfx::Size& pixel_size,
and pixel_size is not in dip? i.e. in DDP? Please be more explicit about this. 
And while your at that, make sure that you say that id is a display id?

https://codereview.chromium.org/2356913002/diff/1/services/ui/display/platfor...
services/ui/display/platform_screen_delegate.h:27: float scale_factor) = 0;
If we have the size in DP and the size in DIP, then the scale_factor is useful?

https://codereview.chromium.org/2356913002/diff/1/services/ui/display/platfor...
File services/ui/display/platform_screen_ozone.cc (right):

https://codereview.chromium.org/2356913002/diff/1/services/ui/display/platfor...
services/ui/display/platform_screen_ozone.cc:33: return (pixel_size.width() /
static_cast<float>(physical_size.width())) *
This might need to be rounded?

https://codereview.chromium.org/2356913002/diff/1/services/ui/display/platfor...
File services/ui/display/platform_screen_ozone.h (right):

https://codereview.chromium.org/2356913002/diff/1/services/ui/display/platfor...
services/ui/display/platform_screen_ozone.h:55: // The display scale factor,
either 1 or 2.
not so. it can be 1.25 yes?

And same blither about scale factor: it can be computed and not passed?

https://codereview.chromium.org/2356913002/diff/1/services/ui/ws/platform_dis...
File services/ui/ws/platform_display.cc (right):

https://codereview.chromium.org/2356913002/diff/1/services/ui/ws/platform_dis...
services/ui/ws/platform_display.cc:87:
delegate_->OnViewportMetricsChanged(ViewportMetrics(), metrics_);
this is required? And if it is, why do you show the window first? The order
seems strange.

https://codereview.chromium.org/2356913002/diff/1/services/ui/ws/platform_dis...
File services/ui/ws/platform_display_init_params.h (left):

https://codereview.chromium.org/2356913002/diff/1/services/ui/ws/platform_dis...
services/ui/ws/platform_display_init_params.h:19: class GpuState;
good cleanup.

https://codereview.chromium.org/2356913002/diff/1/services/ui/ws/viewport_met...
File services/ui/ws/viewport_metrics.h (right):

https://codereview.chromium.org/2356913002/diff/1/services/ui/ws/viewport_met...
services/ui/ws/viewport_metrics.h:17: float device_scale_factor = 0.0f;
see previous blither. cheaper to recompute from the above than to take a cache
miss looking it up

https://codereview.chromium.org/2356913002/diff/1/ui/base/resource/resource_b...
File ui/base/resource/resource_bundle.cc (right):

https://codereview.chromium.org/2356913002/diff/1/ui/base/resource/resource_b...
ui/base/resource/resource_bundle.cc:140: // TODO: Remove before submitting.
please complete TODO

[kylechar, 2016-09-21 16:31:13]

https://codereview.chromium.org/2356913002/diff/1/services/ui/display/platfor...
File services/ui/display/platform_screen_delegate.h (right):

https://codereview.chromium.org/2356913002/diff/1/services/ui/display/platfor...
services/ui/display/platform_screen_delegate.h:26: const gfx::Size& pixel_size,
On 2016/09/21 13:23:46, rjkroege wrote:
> and pixel_size is not in dip? i.e. in DDP? Please be more explicit about this.

> And while your at that, make sure that you say that id is a display id?

Done.

https://codereview.chromium.org/2356913002/diff/1/services/ui/display/platfor...
services/ui/display/platform_screen_delegate.h:27: float scale_factor) = 0;
On 2016/09/21 13:23:46, rjkroege wrote:
> If we have the size in DP and the size in DIP, then the scale_factor is
useful?

Usually, DIP = DDP * (ui_scale_factor / device_scale_factor). In that case we
need at least three of the four values to compute the last. I'm just assuming
ui_scale_factor is 1.0 for now. ash::DisplayManager has all the code that
supports ui_scale_factor (which I don't want to reimplement).

Except there is a special case where ui_scale_factor=0.8 and
device_scale_factor=1.25 so that formula doesn't work. So you probably need all
four values?

https://codereview.chromium.org/2356913002/diff/1/services/ui/display/platfor...
File services/ui/display/platform_screen_ozone.cc (right):

https://codereview.chromium.org/2356913002/diff/1/services/ui/display/platfor...
services/ui/display/platform_screen_ozone.cc:33: return (pixel_size.width() /
static_cast<float>(physical_size.width())) *
On 2016/09/21 13:23:46, rjkroege wrote:
> This might need to be rounded?

Hmm, it's not rounded in DisplayChangeObserver currently.

https://codereview.chromium.org/2356913002/diff/1/services/ui/display/platfor...
File services/ui/display/platform_screen_ozone.h (right):

https://codereview.chromium.org/2356913002/diff/1/services/ui/display/platfor...
services/ui/display/platform_screen_ozone.h:55: // The display scale factor,
either 1 or 2.
On 2016/09/21 13:23:47, rjkroege wrote:
> not so. it can be 1.25 yes?
> 
> And same blither about scale factor: it can be computed and not passed?

It can sort of be 1.25. It's hard to explain without showing it?

For now I'm just ignoring 1.25 in PlatformScreen so the comment is accurate-ish.

https://codereview.chromium.org/2356913002/diff/1/services/ui/ws/platform_dis...
File services/ui/ws/platform_display.cc (right):

https://codereview.chromium.org/2356913002/diff/1/services/ui/ws/platform_dis...
services/ui/ws/platform_display.cc:87:
delegate_->OnViewportMetricsChanged(ViewportMetrics(), metrics_);
On 2016/09/21 13:23:47, rjkroege wrote:
> this is required? And if it is, why do you show the window first? The order
> seems strange.

Yes/no. First, yes it's required because OnViewportMetricsChanged handles two
things. It handles creating the root window and updating viewport metrics.
Second, no it shouldn't be required because it shouldn't work that way.

I've split it into two methods to make it clearer. I'm also creating the root
window before showing the platform window now.

https://codereview.chromium.org/2356913002/diff/1/services/ui/ws/viewport_met...
File services/ui/ws/viewport_metrics.h (right):

https://codereview.chromium.org/2356913002/diff/1/services/ui/ws/viewport_met...
services/ui/ws/viewport_metrics.h:17: float device_scale_factor = 0.0f;
On 2016/09/21 13:23:47, rjkroege wrote:
> see previous blither. cheaper to recompute from the above than to take a cache
> miss looking it up

See my reply in other comment.

[kylechar, 2016-09-21 16:39:52]

Description was changed from

==========
Pass device scale factor from display to ws.

Pass extra info from PlatfromScreen to it's delegate so that the device
bounds in DIP, the pixel size and device scale factor are available. The
WS can then use this information to draw appropriately.

Most of the changes inside PlatformScreenOzone are throw away. The
ash::DisplayManager already has this logic. This isn't ready for use
with mustash yet.

The bounds of the display are in DIP. This is the format that is
expected in clients that receive the bounds via ScreenMus. The pixel
size of the display is needed for creating the PlatformWindow.

BUG=TBD
==========

to

==========
Pass device scale factor from display to ws.

Pass extra info from PlatfromScreen to it's delegate so that the device
bounds in DIP, the pixel size and device scale factor are available. The
WS can then use this information to draw appropriately.

Most of the changes inside PlatformScreenOzone are throw away. The
ash::DisplayManager already has this logic. This isn't ready for use
with mustash yet.

The bounds of the display are in DIP. This is the format that is
expected in clients that receive the bounds via ScreenMus. The pixel
size of the display is needed for creating the PlatformWindow.

BUG=649008
==========

[kylechar, 2016-09-22 19:40:05]

Description was changed from

==========
Pass device scale factor from display to ws.

Pass extra info from PlatfromScreen to it's delegate so that the device
bounds in DIP, the pixel size and device scale factor are available. The
WS can then use this information to draw appropriately.

Most of the changes inside PlatformScreenOzone are throw away. The
ash::DisplayManager already has this logic. This isn't ready for use
with mustash yet.

The bounds of the display are in DIP. This is the format that is
expected in clients that receive the bounds via ScreenMus. The pixel
size of the display is needed for creating the PlatformWindow.

BUG=649008
==========

to

==========
Pass device scale factor from display to ws in mustash.

Pass extra info from PlatfromScreen to it's delegate so that the device
bounds in DIP, the pixel size and device scale factor are available. The
the delegate happens to be the WS and it will use this information to
support high-DIP displays.

Most of the changes inside PlatformScreenOzone are throw away.
ash::DisplayManager already has this logic. We still have to finish
separating ash::DisplayManager from the rest of ash though,
necessitating a bit of code duplication until then.

The bounds of the display are in DIP. This is the format that is
expected from clients that receive the bounds via ScreenMus. The pixel
size of the display is needed for creating the PlatformWindow.

With this change mustash should run in high-DPI mode when running on a
device with a high-DPI internal display. It can also be enabled by
specifying the DPI for the fake display in Ozone X11, for example
--screen-config=800x800^300 will be high-DPI.

BUG=649008
==========

[kylechar, 2016-09-22 20:03:28]

https://codereview.chromium.org/2356913002/diff/1/ui/base/resource/resource_b...
File ui/base/resource/resource_bundle.cc (right):

https://codereview.chromium.org/2356913002/diff/1/ui/base/resource/resource_b...
ui/base/resource/resource_bundle.cc:140: // TODO: Remove before submitting.
On 2016/09/21 13:23:47, rjkroege wrote:
> please complete TODO

Done.

[kylechar, 2016-09-22 20:56:27]

Patchset #3 (id:40001) has been deleted

[kylechar, 2016-09-22 21:03:11]

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

[kylechar, 2016-09-22 21:03:11]

+sky for OWNERS review

[kylechar, 2016-09-22 21:03:36]

Description was changed from

==========
Pass device scale factor from display to ws in mustash.

Pass extra info from PlatfromScreen to it's delegate so that the device
bounds in DIP, the pixel size and device scale factor are available. The
the delegate happens to be the WS and it will use this information to
support high-DIP displays.

Most of the changes inside PlatformScreenOzone are throw away.
ash::DisplayManager already has this logic. We still have to finish
separating ash::DisplayManager from the rest of ash though,
necessitating a bit of code duplication until then.

The bounds of the display are in DIP. This is the format that is
expected from clients that receive the bounds via ScreenMus. The pixel
size of the display is needed for creating the PlatformWindow.

With this change mustash should run in high-DPI mode when running on a
device with a high-DPI internal display. It can also be enabled by
specifying the DPI for the fake display in Ozone X11, for example
--screen-config=800x800^300 will be high-DPI.

BUG=649008
==========

to

==========
Pass device scale factor from display to ws in mustash.

Pass extra info from PlatfromScreen to it's delegate so that the device
bounds in DIP, the pixel size and device scale factor are available. The
the delegate happens to be the WS and it will use this information to
support high-DPI displays.

Most of the changes inside PlatformScreenOzone are throw away.
ash::DisplayManager already has this logic. We still have to finish
separating ash::DisplayManager from the rest of ash though,
necessitating a bit of code duplication until then.

The bounds of the display are in DIP. This is the format that is
expected from clients that receive the bounds via ScreenMus. The pixel
size of the display is needed for creating the PlatformWindow.

With this change mustash should run in high-DPI mode when running on a
device with a high-DPI internal display. It can also be enabled by
specifying the DPI for the fake display in Ozone X11, for example
--screen-config=800x800^300 will be high-DPI.

BUG=649008
==========

[sky, 2016-09-22 21:42:07]

Can you also add an OWNERS file for ui/ws/display with you and Rob in it?

https://codereview.chromium.org/2356913002/diff/60001/services/ui/display/pla...
File services/ui/display/platform_screen_delegate.h (right):

https://codereview.chromium.org/2356913002/diff/60001/services/ui/display/pla...
services/ui/display/platform_screen_delegate.h:30: float device_scale_factor) =
0;
Do you need to specify if the new display is the primary? Same thing with
OnDisplayModified, might it become the primary?

https://codereview.chromium.org/2356913002/diff/60001/services/ui/display/pla...
services/ui/display/platform_screen_delegate.h:36: // Called when a display is
modified. See |OnDisplayAdded| for parameter
Generally we use params for function calls rather than |'s, e.g.,
OnDisplayAdded() rather than |OnDisplayAdded|.

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

https://codereview.chromium.org/2356913002/diff/60001/services/ui/display/pla...
services/ui/display/platform_screen_ozone.h:95: DisplayInfo
DisplayInfoFromSnapshot(ui::DisplaySnapshot* snapshot);
If possible, make this take a const ui::DisplaySnapshot& as it seems like
snapshot shouldn't be modified in this call.

https://codereview.chromium.org/2356913002/diff/60001/services/ui/ws/display.cc
File services/ui/ws/display.cc (right):

https://codereview.chromium.org/2356913002/diff/60001/services/ui/ws/display....
services/ui/ws/display.cc:335: display_manager()->OnDisplayUpdate(this);
Why is it safe to not check init_called?

https://codereview.chromium.org/2356913002/diff/60001/services/ui/ws/platform...
File services/ui/ws/platform_display.cc (left):

https://codereview.chromium.org/2356913002/diff/60001/services/ui/ws/platform...
services/ui/ws/platform_display.cc:274: UpdateMetrics(metrics_.bounds,
device_scale_factor);
Why do we not need to call UpdateMetrics here?

https://codereview.chromium.org/2356913002/diff/60001/services/ui/ws/platform...
File services/ui/ws/platform_display_delegate.h (right):

https://codereview.chromium.org/2356913002/diff/60001/services/ui/ws/platform...
services/ui/ws/platform_display_delegate.h:31: virtual void
CreateRootWindow(const gfx::Size& size);
Naming this CreateRootWindow() is rather specific to what the implementation
does. Isn't this more of something like Init(size)? Also, it's worth clarifying
what units size is in.

https://codereview.chromium.org/2356913002/diff/60001/services/ui/ws/viewport...
File services/ui/ws/viewport_metrics.h (right):

https://codereview.chromium.org/2356913002/diff/60001/services/ui/ws/viewport...
services/ui/ws/viewport_metrics.h:16: gfx::Size pixel_size;  // DDP
// DDP is redundant with 'pixel'.

[kylechar, 2016-09-23 13:22:32]

Done.

https://codereview.chromium.org/2356913002/diff/60001/services/ui/display/pla...
File services/ui/display/platform_screen_delegate.h (right):

https://codereview.chromium.org/2356913002/diff/60001/services/ui/display/pla...
services/ui/display/platform_screen_delegate.h:30: float device_scale_factor) =
0;
On 2016/09/22 21:42:06, sky wrote:
> Do you need to specify if the new display is the primary? Same thing with
> OnDisplayModified, might it become the primary?

PlatformDisplay queries PlatformScreen to check if it's the primary display.
That info gets included in the mojom::WsDisplay that ws::DisplayManager sends
when a display is added/removed/modified. So everything should work fine when a
display is added at least.

Changing the primary display won't really work though. I'll go through that code
path and check it works when I finish ws::DisplayManager::OnDisplayModified()
next. That will require a couple of changes I think.

https://codereview.chromium.org/2356913002/diff/60001/services/ui/display/pla...
services/ui/display/platform_screen_delegate.h:36: // Called when a display is
modified. See |OnDisplayAdded| for parameter
On 2016/09/22 21:42:06, sky wrote:
> Generally we use params for function calls rather than |'s, e.g.,
> OnDisplayAdded() rather than |OnDisplayAdded|.

Done.

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

https://codereview.chromium.org/2356913002/diff/60001/services/ui/display/pla...
services/ui/display/platform_screen_ozone.h:95: DisplayInfo
DisplayInfoFromSnapshot(ui::DisplaySnapshot* snapshot);
On 2016/09/22 21:42:06, sky wrote:
> If possible, make this take a const ui::DisplaySnapshot& as it seems like
> snapshot shouldn't be modified in this call.

Done.

https://codereview.chromium.org/2356913002/diff/60001/services/ui/ws/display.cc
File services/ui/ws/display.cc (right):

https://codereview.chromium.org/2356913002/diff/60001/services/ui/ws/display....
services/ui/ws/display.cc:335: display_manager()->OnDisplayUpdate(this);
On 2016/09/22 21:42:06, sky wrote:
> Why is it safe to not check init_called?

OnDisplayUpdate() was getting called during initialization when the root
ServerWindow was created but before the ash WindowTreeClient was done updating.

The root ServerWindow creation happens in CreateRootWindow() now so that isn't a
problem.

https://codereview.chromium.org/2356913002/diff/60001/services/ui/ws/platform...
File services/ui/ws/platform_display.cc (left):

https://codereview.chromium.org/2356913002/diff/60001/services/ui/ws/platform...
services/ui/ws/platform_display.cc:274: UpdateMetrics(metrics_.bounds,
device_scale_factor);
On 2016/09/22 21:42:06, sky wrote:
> Why do we not need to call UpdateMetrics here?

This was actually the equivalent to CreateRootWindow (the first half of
UpdateMetrics). We know the window size before here so it seems like it's better
to create the root window with the rest of the initialization?

https://codereview.chromium.org/2356913002/diff/60001/services/ui/ws/platform...
File services/ui/ws/platform_display_delegate.h (right):

https://codereview.chromium.org/2356913002/diff/60001/services/ui/ws/platform...
services/ui/ws/platform_display_delegate.h:31: virtual void
CreateRootWindow(const gfx::Size& size);
On 2016/09/22 21:42:06, sky wrote:
> Naming this CreateRootWindow() is rather specific to what the implementation
> does. Isn't this more of something like Init(size)? Also, it's worth
clarifying
> what units size is in.

I've added the units for size. Unfortunately there is already a Display::Init()
method that does something else which depends on the root ServerWindow existing.

In general though, the creation of Display/PlatformDisplay could be simplified
with a bit of work.

https://codereview.chromium.org/2356913002/diff/60001/services/ui/ws/viewport...
File services/ui/ws/viewport_metrics.h (right):

https://codereview.chromium.org/2356913002/diff/60001/services/ui/ws/viewport...
services/ui/ws/viewport_metrics.h:16: gfx::Size pixel_size;  // DDP
On 2016/09/22 21:42:06, sky wrote:
> // DDP is redundant with 'pixel'.

Done.

[rjkroege, 2016-09-23 13:56:23]

lgtm (with nit or misreading on my part)

https://codereview.chromium.org/2356913002/diff/1/services/ui/display/platfor...
File services/ui/display/platform_screen_ozone.cc (right):

https://codereview.chromium.org/2356913002/diff/1/services/ui/display/platfor...
services/ui/display/platform_screen_ozone.cc:33: return (pixel_size.width() /
static_cast<float>(physical_size.width())) *
On 2016/09/21 16:31:12, kylechar wrote:
> On 2016/09/21 13:23:46, rjkroege wrote:
> > This might need to be rounded?
> 
> Hmm, it's not rounded in DisplayChangeObserver currently.

OK. But I bet that's caused at least one bug. :-)

https://codereview.chromium.org/2356913002/diff/80001/services/ui/ws/platform...
File services/ui/ws/platform_display_delegate.h (right):

https://codereview.chromium.org/2356913002/diff/80001/services/ui/ws/platform...
services/ui/ws/platform_display_delegate.h:14: namespace ui {
nit: why two namespace ui?

[kylechar, 2016-09-23 14:22:28]

https://codereview.chromium.org/2356913002/diff/80001/services/ui/ws/platform...
File services/ui/ws/platform_display_delegate.h (right):

https://codereview.chromium.org/2356913002/diff/80001/services/ui/ws/platform...
services/ui/ws/platform_display_delegate.h:14: namespace ui {
On 2016/09/23 13:56:23, rjkroege wrote:
> nit: why two namespace ui?

Probably something like "s/namespace mus/namespace ui/" cause it? Fixed.

[kylechar, 2016-09-23 14:33:50]

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

[commit-bot: I haz the power, 2016-09-23 14:33: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-09-23 14:47:39]

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

[commit-bot: I haz the power, 2016-09-23 14:47:40]

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

[rjkroege, 2016-09-23 16:46:24]

On 2016/09/23 14:22:28, kylechar wrote:
>
https://codereview.chromium.org/2356913002/diff/80001/services/ui/ws/platform...
> File services/ui/ws/platform_display_delegate.h (right):
> 
>
https://codereview.chromium.org/2356913002/diff/80001/services/ui/ws/platform...
> services/ui/ws/platform_display_delegate.h:14: namespace ui {
> On 2016/09/23 13:56:23, rjkroege wrote:
> > nit: why two namespace ui?
> 
> Probably something like "s/namespace mus/namespace ui/" cause it? Fixed.

still lgtm

[sky, 2016-09-23 17:57:54]

LGTM

[kylechar, 2016-09-23 19:18:32]

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

[commit-bot: I haz the power, 2016-09-23 19:19:02]

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-09-23 20:25:43]

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

[commit-bot: I haz the power, 2016-09-23 20:25:44]

Dry run: This issue passed the CQ dry run.

[kylechar, 2016-09-23 22:20:36]

The CQ bit was checked by kylechar@chromium.org

[kylechar, 2016-09-23 22:20:36]

The patchset sent to the CQ was uploaded after l-g-t-m from
rjkroege@chromium.org, sky@chromium.org
Link to the patchset: https://codereview.chromium.org/2356913002/#ps120001
(title: "Fix more tests.")

[commit-bot: I haz the power, 2016-09-23 22:21:08]

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-09-23 22:48:03]

Description was changed from

==========
Pass device scale factor from display to ws in mustash.

Pass extra info from PlatfromScreen to it's delegate so that the device
bounds in DIP, the pixel size and device scale factor are available. The
the delegate happens to be the WS and it will use this information to
support high-DPI displays.

Most of the changes inside PlatformScreenOzone are throw away.
ash::DisplayManager already has this logic. We still have to finish
separating ash::DisplayManager from the rest of ash though,
necessitating a bit of code duplication until then.

The bounds of the display are in DIP. This is the format that is
expected from clients that receive the bounds via ScreenMus. The pixel
size of the display is needed for creating the PlatformWindow.

With this change mustash should run in high-DPI mode when running on a
device with a high-DPI internal display. It can also be enabled by
specifying the DPI for the fake display in Ozone X11, for example
--screen-config=800x800^300 will be high-DPI.

BUG=649008
==========

to

==========
Pass device scale factor from display to ws in mustash.

Pass extra info from PlatfromScreen to it's delegate so that the device
bounds in DIP, the pixel size and device scale factor are available. The
the delegate happens to be the WS and it will use this information to
support high-DPI displays.

Most of the changes inside PlatformScreenOzone are throw away.
ash::DisplayManager already has this logic. We still have to finish
separating ash::DisplayManager from the rest of ash though,
necessitating a bit of code duplication until then.

The bounds of the display are in DIP. This is the format that is
expected from clients that receive the bounds via ScreenMus. The pixel
size of the display is needed for creating the PlatformWindow.

With this change mustash should run in high-DPI mode when running on a
device with a high-DPI internal display. It can also be enabled by
specifying the DPI for the fake display in Ozone X11, for example
--screen-config=800x800^300 will be high-DPI.

BUG=649008
==========

[commit-bot: I haz the power, 2016-09-23 22:48:05]

Committed patchset #6 (id:120001)

[commit-bot: I haz the power, 2016-09-23 22:50:55]

Description was changed from

==========
Pass device scale factor from display to ws in mustash.

Pass extra info from PlatfromScreen to it's delegate so that the device
bounds in DIP, the pixel size and device scale factor are available. The
the delegate happens to be the WS and it will use this information to
support high-DPI displays.

Most of the changes inside PlatformScreenOzone are throw away.
ash::DisplayManager already has this logic. We still have to finish
separating ash::DisplayManager from the rest of ash though,
necessitating a bit of code duplication until then.

The bounds of the display are in DIP. This is the format that is
expected from clients that receive the bounds via ScreenMus. The pixel
size of the display is needed for creating the PlatformWindow.

With this change mustash should run in high-DPI mode when running on a
device with a high-DPI internal display. It can also be enabled by
specifying the DPI for the fake display in Ozone X11, for example
--screen-config=800x800^300 will be high-DPI.

BUG=649008
==========

to

==========
Pass device scale factor from display to ws in mustash.

Pass extra info from PlatfromScreen to it's delegate so that the device
bounds in DIP, the pixel size and device scale factor are available. The
the delegate happens to be the WS and it will use this information to
support high-DPI displays.

Most of the changes inside PlatformScreenOzone are throw away.
ash::DisplayManager already has this logic. We still have to finish
separating ash::DisplayManager from the rest of ash though,
necessitating a bit of code duplication until then.

The bounds of the display are in DIP. This is the format that is
expected from clients that receive the bounds via ScreenMus. The pixel
size of the display is needed for creating the PlatformWindow.

With this change mustash should run in high-DPI mode when running on a
device with a high-DPI internal display. It can also be enabled by
specifying the DPI for the fake display in Ozone X11, for example
--screen-config=800x800^300 will be high-DPI.

BUG=649008

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

[commit-bot: I haz the power, 2016-09-23 22:50:56]

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