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

chrome/browser/ui/views/tabs/tab_strip.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 "chrome/browser/ui/views/tabs/tab_strip.h"
 
 #include <algorithm>
 #include <iterator>
 #include <string>
 #include <vector>
@@ skipping 43 matching lines @@
 #include "ui/views/masked_targeter_delegate.h"
 #include "ui/views/mouse_watcher_view_host.h"
 #include "ui/views/rect_based_targeting_utils.h"
 #include "ui/views/view_model_utils.h"
 #include "ui/views/view_targeter.h"
 #include "ui/views/widget/root_view.h"
 #include "ui/views/widget/widget.h"
 #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"
 #endif
 
 using base::UserMetricsAction;
 using ui::DropTargetEvent;
 
 namespace {
 
@@ skipping 229 matching lines @@
 NewTabButton::~NewTabButton() {
   if (destroyed_)
     *destroyed_ = true;
 }
 
 #if defined(OS_WIN)
 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);
     if (destroyed)
       return;
 
     destroyed_ = NULL;
     SetState(views::CustomButton::STATE_NORMAL);
     return;
   }
@@ skipping 2363 matching lines @@
           ConvertPointToViewAndGetEventHandler(this, newtab_button_, point);
       if (view)
         return view;
     }
     Tab* tab = FindTabForEvent(point);
     if (tab)
       return ConvertPointToViewAndGetEventHandler(this, tab, point);
   }
   return this;
 }