mus/views: Fix creating gfx::Display in high-dpi.

mus/views: Fix creating gfx::Display in high-dpi.

It's very easy to create a gfx::Display instance with incorrect values
for bounds/work-area when device-scale factor ≠ 1. This is because
when the gfx::Display is created with a specified bounds, it attempts
to automatically convert the bounds from pixel to DIP values. However,
work-area needs to set separately, and so the caller can use different
scaling factor when setting the bounds vs. setting the work-area. To
fix this, have the gfx::Display creator explicitly do the pixel-to-DIP
conversion before setting the bounds and work-area on the gfx::Display
instances.

BUG=600815, 605124
Committed: https://crrev.com/5b115788789b08177b4f38d9a0206a6c069ec4e6
Cr-Commit-Position: refs/heads/master@{#388507}

[sadrul, 2016-04-20 02:14:34]

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

[sky, 2016-04-20 14:40:10]

https://codereview.chromium.org/1903003002/diff/1/ui/aura/test/aura_test_help...
File ui/aura/test/aura_test_helper.cc (right):

https://codereview.chromium.org/1903003002/diff/1/ui/aura/test/aura_test_help...
ui/aura/test/aura_test_helper.cc:74:
host_.reset(test_screen_->CreateHostForPrimaryDisplay());
If there is a screen will creating host_ at a different size cause problems?

[sadrul, 2016-04-20 14:51:37]

Description was changed from

==========
mus/views: Fix creating gfx::Display in high-dpi.

It's very easy to create a gfx::Display instance with incorrect values
for bounds/work-area when device-scale factor ≠ 1. This is because
when the gfx::Display is created with a specified bounds, it attempts
to automatically convert the bounds from pixel to DIP values. However,
work-area needs to set separately, and so the caller can use different
scaling factor when setting the bounds vs. setting the work-area. To
fix this, have the gfx::Display creator explicitly do the pixel-to-DIP
conversion before setting the bounds and work-area on the gfx::Display
instances.

BUG=600815
==========

to

==========
mus/views: Fix creating gfx::Display in high-dpi.

It's very easy to create a gfx::Display instance with incorrect values
for bounds/work-area when device-scale factor ≠ 1. This is because
when the gfx::Display is created with a specified bounds, it attempts
to automatically convert the bounds from pixel to DIP values. However,
work-area needs to set separately, and so the caller can use different
scaling factor when setting the bounds vs. setting the work-area. To
fix this, have the gfx::Display creator explicitly do the pixel-to-DIP
conversion before setting the bounds and work-area on the gfx::Display
instances.

BUG=600815, 605124
==========

[sadrul, 2016-04-20 14:53:17]

https://codereview.chromium.org/1903003002/diff/1/ui/aura/test/aura_test_help...
File ui/aura/test/aura_test_helper.cc (right):

https://codereview.chromium.org/1903003002/diff/1/ui/aura/test/aura_test_help...
ui/aura/test/aura_test_helper.cc:74:
host_.reset(test_screen_->CreateHostForPrimaryDisplay());
On 2016/04/20 14:40:10, sky wrote:
> If there is a screen will creating host_ at a different size cause problems?

Not sure; the trybots seem happy. But changed this so the TestScreen instance is
created using the existing Screen instance's display size. That should make sure
the WindowTreeHost is created at the size of the primary Display instance.

[sky, 2016-04-20 15:14:08]

LGTM

[sadrul, 2016-04-20 15:57:39]

The CQ bit was checked by sadrul@chromium.org

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

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1903003002/20001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1903003002/20001

[commit-bot: I haz the power, 2016-04-20 16:02:29]

Description was changed from

==========
mus/views: Fix creating gfx::Display in high-dpi.

It's very easy to create a gfx::Display instance with incorrect values
for bounds/work-area when device-scale factor ≠ 1. This is because
when the gfx::Display is created with a specified bounds, it attempts
to automatically convert the bounds from pixel to DIP values. However,
work-area needs to set separately, and so the caller can use different
scaling factor when setting the bounds vs. setting the work-area. To
fix this, have the gfx::Display creator explicitly do the pixel-to-DIP
conversion before setting the bounds and work-area on the gfx::Display
instances.

BUG=600815, 605124
==========

to

==========
mus/views: Fix creating gfx::Display in high-dpi.

It's very easy to create a gfx::Display instance with incorrect values
for bounds/work-area when device-scale factor ≠ 1. This is because
when the gfx::Display is created with a specified bounds, it attempts
to automatically convert the bounds from pixel to DIP values. However,
work-area needs to set separately, and so the caller can use different
scaling factor when setting the bounds vs. setting the work-area. To
fix this, have the gfx::Display creator explicitly do the pixel-to-DIP
conversion before setting the bounds and work-area on the gfx::Display
instances.

BUG=600815, 605124
==========

[commit-bot: I haz the power, 2016-04-20 16:02:30]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2016-04-22 19:23:52]

Description was changed from

==========
mus/views: Fix creating gfx::Display in high-dpi.

It's very easy to create a gfx::Display instance with incorrect values
for bounds/work-area when device-scale factor ≠ 1. This is because
when the gfx::Display is created with a specified bounds, it attempts
to automatically convert the bounds from pixel to DIP values. However,
work-area needs to set separately, and so the caller can use different
scaling factor when setting the bounds vs. setting the work-area. To
fix this, have the gfx::Display creator explicitly do the pixel-to-DIP
conversion before setting the bounds and work-area on the gfx::Display
instances.

BUG=600815, 605124
==========

to

==========
mus/views: Fix creating gfx::Display in high-dpi.

It's very easy to create a gfx::Display instance with incorrect values
for bounds/work-area when device-scale factor ≠ 1. This is because
when the gfx::Display is created with a specified bounds, it attempts
to automatically convert the bounds from pixel to DIP values. However,
work-area needs to set separately, and so the caller can use different
scaling factor when setting the bounds vs. setting the work-area. To
fix this, have the gfx::Display creator explicitly do the pixel-to-DIP
conversion before setting the bounds and work-area on the gfx::Display
instances.

BUG=600815, 605124

Committed: https://crrev.com/5b115788789b08177b4f38d9a0206a6c069ec4e6
Cr-Commit-Position: refs/heads/master@{#388507}
==========

[commit-bot: I haz the power, 2016-04-22 19:23:52]

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