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

chrome/browser/ui/views/tabs/tab_strip.cc

Index: chrome/browser/ui/views/tabs/tab_strip.cc
diff --git a/chrome/browser/ui/views/tabs/tab_strip.cc b/chrome/browser/ui/views/tabs/tab_strip.cc
index 5269e9947f96702fd54e6fc6d967b17fed866020..b6d12a55826257c0c569b059e622d355fd2c8cba 100644
--- a/chrome/browser/ui/views/tabs/tab_strip.cc
+++ b/chrome/browser/ui/views/tabs/tab_strip.cc
@@ -61,7 +61,7 @@
 #include "ui/views/window/non_client_view.h"
 
 #if defined(OS_WIN)
-#include "ui/gfx/win/dpi.h"
+#include "ui/gfx/screen_win.h"
 #include "ui/gfx/win/hwnd_util.h"
 #include "ui/views/widget/monitor_win.h"
 #include "ui/views/win/hwnd_util.h"
@@ -311,7 +311,7 @@ void NewTabButton::OnMouseReleased(const ui::MouseEvent& event) {
   if (event.IsOnlyRightMouseButton()) {
     gfx::Point point = event.location();
     views::View::ConvertPointToScreen(this, &point);
-    point = gfx::win::DIPToScreenPoint(point);
+    point = gfx::ScreenWin::DIPToScreenPoint(point);

[scottmg, 2015/10/28 18:48:21]

Will this need an HWND in the future?

[robliao, 2015/10/29 00:30:24]

At the moment, I don't think so. Callers that have points sensitive to the HWND
context should probably be using the Client point converters.

The common case seems to be HWND free screen points. If there is a compelling
case otherwise, then I could see selected uses take an HWND.

An interesting case in the multiple DPI world is if an HWND spans multiple
monitors and the app asks for a screen point that resides outside of the nearest
monitor.

In certain cases (like GetCursorPos) for virtualized applications, Windows will
actually provide a point referenced to the nearest monitor in the HWND's
context. This means there is some overlap in the physical screen pixel space. 

Incidentally, we are broken today with Windows default virtualization. When the
Chrome window is associated to one monitor and the Chrome menu button is drawn
on another monitor of a different DPI, the menu will render on the Chrome
monitor and not underneath the button. Of course this presents interesting
questions to the Window manager as it needs to render the menu in a different
DPI as well, but it looks like it does not handle this either.

     bool destroyed = false;
     destroyed_ = &destroyed;
     gfx::ShowSystemMenuAtPoint(views::HWNDForView(this), point);