Initialize device scale factor correctly on Android

content/renderer/render_widget.cc

Index: content/renderer/render_widget.cc
diff --git a/content/renderer/render_widget.cc b/content/renderer/render_widget.cc
index 9e723b5cc14f45f8ac68f62d6c46b406f2156fd9..70b057dc311b347bb1a2a7c7c0da4fb53917344d 100644
--- a/content/renderer/render_widget.cc
+++ b/content/renderer/render_widget.cc
@@ -35,6 +35,7 @@
 #include "third_party/WebKit/Source/WebKit/chromium/public/platform/WebString.h"
 #include "third_party/skia/include/core/SkShader.h"
 #include "ui/base/ui_base_switches.h"
+#include "ui/gfx/display.h"
 #include "ui/gfx/rect_conversions.h"
 #include "ui/gfx/size_conversions.h"
 #include "ui/gfx/skia_util.h"
@@ -118,18 +119,14 @@ RenderWidget::RenderWidget(WebKit::WebPopupType popup_type,
   DCHECK(RenderThread::Get());
   has_disable_gpu_vsync_switch_ = CommandLine::ForCurrentProcess()->HasSwitch(
       switches::kDisableGpuVsync);
-#if defined(OS_CHROMEOS) || defined(OS_MACOSX)
-  device_scale_factor_ = screen_info.verticalDPI / kStandardDPI;
-  // Unless an explicit scale factor was provided for testing, ensure the scale
-  // is integral.
-  if (!CommandLine::ForCurrentProcess()->HasSwitch(
-      switches::kForceDeviceScaleFactor))
-    device_scale_factor_ = static_cast<int>(device_scale_factor_);
-  device_scale_factor_ = std::max(1.0f, device_scale_factor_);
-#endif
   is_threaded_compositing_enabled_ =
       CommandLine::ForCurrentProcess()->HasSwitch(
           switches::kEnableThreadedCompositing);
+
+  scoped_ptr<gfx::Display> display(new gfx::Display());
+  display->SetScaleAndBounds(

[johnme, 2012/11/06 15:45:34]

Would it make sense to make a new constructor for Display which accepts a
screen_info and automatically calls SetScaleAndBounds with this scale factor, so
we can move even more logic out of render_widget? jamesr? oshima?

[Sami, 2012/11/06 17:08:47]

Good idea, that makes things a little cleaner. Someone correct me if I'm wrong,
but since WebScreenInfo is a public WebKit class we can use it from
gfx::Display.

+      screen_info.verticalDPI / kStandardDPI, display->bounds());

[johnme, 2012/11/06 15:45:34]

Presumably this works on Android because in practice we initialize
screen_info.verticalDPI to device_info->GetDPIScale() * 160? We definitely
shouldn't be relying on DisplayMetrics's xdpi and ydpi, as those are
unreliable/deprecated.

Nit: I'd rather we used horizontalDPI instead of verticalDPI, since one of the
most important uses for the scale is determining the device-width that will be
used in mobile viewports. Alternatively, even better is probably to use
min(horizontalDPI, verticalDPI).

P.S. I notice that Mac and CrOS are using the wrong kStandardDPI; I filed
http://crbug.com/159603 about that (ultimately recommending that we move
chromium away from dealing with dpi to dealing purely in device scale factors).

[Sami, 2012/11/06 17:08:47]

That's right, and based on the discussion it seems like some of the other ports
are doing it as well.
I went for your min(hdpi, vdpi) suggestion. I checked that Android, Mac and CrOS
seem to be initializing both horizontal and vertical DPI to the same value, so
in practice this probably won't matter.
 

+  device_scale_factor_ = display->device_scale_factor();
 }
 
 RenderWidget::~RenderWidget() {