summaryrefslogtreecommitdiffstats
path: root/ui/aura
diff options
context:
space:
mode:
authorpkasting <pkasting@chromium.org>2015-12-17 00:35:24 -0800
committerCommit bot <commit-bot@chromium.org>2015-12-17 08:36:27 +0000
commit91475b0fc7403a184929aab5118f7e5b420f3c99 (patch)
tree45a0bedcc4ac4912b87b910ce9a710612a97b47a /ui/aura
parentc03d9fa3fb213991e0e2abbcff8f66e5cfc55eeb (diff)
downloadchromium_src-91475b0fc7403a184929aab5118f7e5b420f3c99.zip
chromium_src-91475b0fc7403a184929aab5118f7e5b420f3c99.tar.gz
chromium_src-91475b0fc7403a184929aab5118f7e5b420f3c99.tar.bz2
Correctly handle system metrics with e.g. --force-device-scale-factor.
Because GetSystemMetrics() always reflects the true current system DPI, it's not appropriate to scale its result by GetDPIScale(); this results in the wrong value when GetDPIScale() is forced to return a scale factor different than the native one. (It's not 100% clear to me whether the "clamp <=1.25 to 1" code should still be applied in this case, but I think not.) However, simply changing GetSystemMetricsInDIP() to use GetUnforcedDeviceScaleFactor() is insufficient, because that function will preferentially return |g_device_scale_factor|, which was being initialized to the result of GetDPIScale() in two places. This doesn't actually make any sense when you think through it. * When there was a forced device scale factor, this meant that GetUnforcedDeviceScaleFactor() was returning this forced scale. This makes no difference to anything except the updated version of GetSystemMetricsInDIP(), which would be unable to access the non-forced scale factor. * When there wasn't a forced device scale factor, and the unforced DPI was 1.0 or >1.25, this simply meant that GetUnforcedDeviceScaleFactor() would return, as a cached value, the value it would have returned anyway. The extra caching doesn't buy anything meaningful performance-wise since GetDPI() already caches internally, so this would have no discernable effect. * Finally, when there was no forced device scale factor and the DPI was between 1 and 1.25, this would mean GetUnforcedDeviceScaleFactor() would display the same clamping behavior GetDPIScale() would. Again, this makes no difference to anything except the updated version of GetSystemMetricsInDIP(). So, without my change in GetSystemMetricsInDIP(), the two calls to InitDeviceScaleFactor() I've removed will have no behavioral effect; with that change, removing them is required in order to get the desired behavior, namely, what the name "GetUnforcedDeviceScaleFactor()" actually suggests. BUG=none TEST=On Windows, running with --force-device-scale-factor=2 should result in a height above the main toolbar that's exactly double the normal height, instead of being shorter. Review URL: https://codereview.chromium.org/1520283005 Cr-Commit-Position: refs/heads/master@{#365784}
Diffstat (limited to 'ui/aura')
-rw-r--r--ui/aura/demo/demo_main.cc2
1 files changed, 1 insertions, 1 deletions
diff --git a/ui/aura/demo/demo_main.cc b/ui/aura/demo/demo_main.cc
index 689f87d..b76dde2 100644
--- a/ui/aura/demo/demo_main.cc
+++ b/ui/aura/demo/demo_main.cc
@@ -129,7 +129,7 @@ int DemoMain() {
gfx::GLSurface::InitializeOneOff();
#if defined(OS_WIN)
- gfx::InitDeviceScaleFactor(1.0f);
+ gfx::SetDefaultDeviceScaleFactor(1.0f);
#endif
// The ContextFactory must exist before any Compositors are created.