Use actual value of display scale factor from GetMonitorScaleFactor().

ui/display/win/screen_win.cc

 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "ui/display/win/screen_win.h"
 
 #include <windows.h>
 #include <shellscalingapi.h>
 
 #include <algorithm>
@@ skipping 422 matching lines @@
   HWND hwnd = view ? GetHWNDFromNativeView(view) : nullptr;
   return ScreenToDIPRect(hwnd, screen_rect);
 }
 
 gfx::Rect ScreenWin::DIPToScreenRectInWindow(gfx::NativeView view,
                                              const gfx::Rect& dip_rect) const {
   HWND hwnd = view ? GetHWNDFromNativeView(view) : nullptr;
   return DIPToScreenRect(hwnd, dip_rect);
 }
 
+float ScreenWin::GetScaleFactorForWindow(gfx::NativeView view) const {
+  HWND hwnd = view ? GetHWNDFromNativeView(view) : nullptr;
+  return GetMonitorScaleFactor(

[Andrey Kraynov, 2016/11/16 18:33:47]

Another possible and simple way to fix this issue is to handle WM_DPICHANGED in
ScreenWin::OnWndProc and update displays.
But I failed to get it there. Should ScreenWin::OnWndProc() function receive
WM_DPICHANGED event?

[sadrul, 2016/11/16 20:38:17]

I think that would make sense, yeah. Is that possible to do? Looks like it
currently processes only WM_DISPLAYCHAGE, but WM_DPICHANGED would be something
it should process too.

[robliao, 2016/11/16 20:56:17]

WM_DPICHANGED is fired when an HWND is associated with a different DPI. This is
principally for per-monitor DPI window changes when you drag a window from one
screen to the other but can happen when you change the DPI of the HWND's current
display.

The SingletonHwnd is bound to the primary display at (0,0) with (0,0) size. As a
result, it will only get WM_DPICHANGED for the primary display. If change the
DPI on a secondary display, you may not receive a WM_DPICHANGED.

Taking a step back, I'm seeing WM_DISPLAYCHANGED fired first and then
WM_DPICHANGED.
This ordering is important from Windows's point for view for the reasons
described in the bug, applications that are doing display tracking like we are
need to update their metrics first before firing the WM_DPICHANGED.

I'll loop this discussion into the bug, but the main question I have is how does
one get WM_DPICHANGED to fire before WM_DISPLAYCHANGED?

+      ::MonitorFromWindow(hwnd, MONITOR_DEFAULTTOPRIMARY));
+}
+
 void ScreenWin::UpdateFromDisplayInfos(
     const std::vector<DisplayInfo>& display_infos) {
   screen_win_displays_ = DisplayInfosToScreenWinDisplays(display_infos);
 }
 
 void ScreenWin::Initialize() {
   singleton_hwnd_observer_.reset(
       new gfx::SingletonHwndObserver(
           base::Bind(&ScreenWin::OnWndProc, base::Unretained(this))));
   UpdateFromDisplayInfos(GetDisplayInfosFromSystem());
@@ skipping 27 matching lines @@
   return ::GetSystemMetrics(metric);
 }
 
 void ScreenWin::OnWndProc(HWND hwnd,
                           UINT message,
                           WPARAM wparam,
                           LPARAM lparam) {
   if (message != WM_DISPLAYCHANGE)
     return;
 
+  LOG(ERROR) << "ScreenWin::OnWndProc(WM_DISPLAYCHANGE)";
   std::vector<display::Display> old_displays = GetAllDisplays();
   UpdateFromDisplayInfos(GetDisplayInfosFromSystem());
   change_notifier_.NotifyDisplaysChanged(old_displays, GetAllDisplays());
 }
 
 ScreenWinDisplay ScreenWin::GetScreenWinDisplayNearestHWND(HWND hwnd)
     const {
   return GetScreenWinDisplay(MonitorInfoFromWindow(hwnd,
                                                    MONITOR_DEFAULTTONEAREST));
 }
@@ skipping 88 matching lines @@
     if (std::find(unique_scale_factors.begin(), unique_scale_factors.end(),
                   reported_scale) == unique_scale_factors.end()) {
       unique_scale_factors.push_back(reported_scale);
       UMA_HISTOGRAM_SPARSE_SLOWLY("UI.DeviceScale", reported_scale);
     }
   }
 }
 
 }  // namespace win
 }  // namespace display