Refactor Windows DPI Point, Rect, and Size for Multiple Monitor DPI Awareness

chrome/browser/ui/views/frame/browser_desktop_window_tree_host_win.cc

Index: chrome/browser/ui/views/frame/browser_desktop_window_tree_host_win.cc
diff --git a/chrome/browser/ui/views/frame/browser_desktop_window_tree_host_win.cc b/chrome/browser/ui/views/frame/browser_desktop_window_tree_host_win.cc
index 20d64e9867f11170e98b2945c3e98950bf3d1cd1..3387e7740634088677a36111dfb689ba247114e8 100644
--- a/chrome/browser/ui/views/frame/browser_desktop_window_tree_host_win.cc
+++ b/chrome/browser/ui/views/frame/browser_desktop_window_tree_host_win.cc
@@ -20,7 +20,7 @@
 #include "chrome/browser/ui/views/theme_image_mapper.h"
 #include "chrome/common/chrome_constants.h"
 #include "ui/base/theme_provider.h"
-#include "ui/gfx/win/dpi.h"
+#include "ui/gfx/screen_win.h"
 #include "ui/views/controls/menu/native_menu_win.h"
 
 #pragma comment(lib, "dwmapi.lib")
@@ -320,7 +320,8 @@ MARGINS BrowserDesktopWindowTreeHostWin::GetDWMFrameMargins() const {
     if (!browser_view_->IsFullscreen()) {
       gfx::Rect tabstrip_bounds(
           browser_frame_->GetBoundsForTabStrip(browser_view_->tabstrip()));
-      tabstrip_bounds = gfx::win::DIPToScreenRect(tabstrip_bounds);
+      tabstrip_bounds = gfx::ScreenWin::DIPToClientRect(GetHWND(),

[sky, 2015/10/29 15:51:50]

Is there a reason for changing the name of these functions? Isn't screen rect
more consistent with what the function returns and naming else where?

I also think the scale factor should be available at the widget level so that
you don't have to dig out the hwnd.

[robliao, 2015/11/07 00:56:40]

When I audited this function, I found the calculation was not performed relative
to the screen coordinate system but rather the HWND's or client's coordinate
system, hence the change. This is necessary since scaling a client means we
don't have to worry about screen origins. For rects calculated with respect to
screen origins, a transformation is possible especially if an HWND spans
multiple monitors since this implementation anchors the screen origins to handle
the multiple DPIs.

The HWND seemed to be a good lowest common denominator everyone had. My hand was
forced by TooltipWin which reasons over HWNDs and has no access to views or
widgets, so HWNDs are used for commonality. 

+                                                        tabstrip_bounds);
       margins.cyTopHeight = tabstrip_bounds.bottom();
 
       // On pre-Win 10, we need to offset the DWM frame into the toolbar so that