Bug 1087964 - Remove OS X resolution-changing hack from DoResetWidgetBounds, and get the scale from the device context instead (because it will be up to date already, while the widget may not); and fix scaling in nsCocoaWindow::Resize to work properly with custom devPixelsPerPx. r=mstange
authorJonathan Kew <jkew@mozilla.com>
Wed, 11 May 2016 11:04:21 +0100
changeset 297201 5c10dc50527edbaf800f276697a1272765ea8149
parent 297200 546b3763d1b6d2c3d64b34b9d9d25d346b805996
child 297202 00b8a2d2825fc16d33cc7ae83454e9f3538716d1
push id30253
push usercbook@mozilla.com
push dateFri, 13 May 2016 09:59:43 +0000
treeherdermozilla-central@5a2deb5a9b09 [default view] [failures only]
perfherder[talos] [build metrics] [platform microbench] (compared to previous push)
reviewersmstange
bugs1087964
milestone49.0a1
first release with
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
last release without
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
Bug 1087964 - Remove OS X resolution-changing hack from DoResetWidgetBounds, and get the scale from the device context instead (because it will be up to date already, while the widget may not); and fix scaling in nsCocoaWindow::Resize to work properly with custom devPixelsPerPx. r=mstange
view/nsView.cpp
widget/cocoa/nsCocoaWindow.mm
--- a/view/nsView.cpp
+++ b/view/nsView.cpp
@@ -335,36 +335,17 @@ void nsView::DoResetWidgetBounds(bool aM
   bool changedSize = curBounds.Size() != newBounds.Size();
 
   // Child views are never attached to top level widgets, this is safe.
 
   // Coordinates are converted to desktop pixels for window Move/Resize APIs,
   // because of the potential for device-pixel coordinate spaces for mixed
   // hidpi/lodpi screens to overlap each other and result in bad placement
   // (bug 814434).
-  DesktopToLayoutDeviceScale scale = widget->GetDesktopToDeviceScale();
-
-#ifdef XP_MACOSX
-  // On OS X, this can be called before Cocoa has updated the backing scale
-  // factor of our widget, in which case |scale| is wrong here. To work
-  // around this, we check the device context and override |scale| if it
-  // doesn't match. (This happens when a popup window that has previously
-  // been created and hidden is being moved between hi- and lo-dpi screens,
-  // but is not currently visible; Cocoa doesn't notify it of the scale
-  // factor change until it gets shown on the new screen, which is too late
-  // for us because we'll have already done the computations involving scale
-  // here to move/size it.)
-  // It might be better to avoid this by keeping calculations such as
-  // CalcWidgetBounds entirely in appUnits, rather than using device pixels,
-  // but that seems like a more extensive and potentially risky change.
-  int32_t appPerDev = dx->AppUnitsPerDevPixelAtUnitFullZoom();
-  if (NSToIntRound(60.0 / scale.scale) != appPerDev) {
-    scale = DesktopToLayoutDeviceScale(60.0 / appPerDev);
-  }
-#endif
+  DesktopToLayoutDeviceScale scale = dx->GetDesktopToDeviceScale();
 
   DesktopRect deskRect = newBounds / scale;
   if (changedPos) {
     if (changedSize && !aMoveOnly) {
       widget->ResizeClient(deskRect.x, deskRect.y,
                            deskRect.width, deskRect.height,
                            aInvalidateChangedSize);
     } else {
--- a/widget/cocoa/nsCocoaWindow.mm
+++ b/widget/cocoa/nsCocoaWindow.mm
@@ -1583,17 +1583,17 @@ NS_IMETHODIMP nsCocoaWindow::Resize(doub
                                     bool aRepaint)
 {
   return DoResize(aX, aY, aWidth, aHeight, aRepaint, false);
 }
 
 // Coordinates are desktop pixels
 NS_IMETHODIMP nsCocoaWindow::Resize(double aWidth, double aHeight, bool aRepaint)
 {
-  double invScale = 1.0 / GetDefaultScale().scale;
+  double invScale = 1.0 / BackingScaleFactor();
   return DoResize(mBounds.x * invScale, mBounds.y * invScale,
                   aWidth, aHeight, aRepaint, true);
 }
 
 NS_IMETHODIMP nsCocoaWindow::GetClientBounds(mozilla::LayoutDeviceIntRect& aRect)
 {
   NS_OBJC_BEGIN_TRY_ABORT_BLOCK_NSRESULT;