Update IOSurface scale factor before compare

content/browser/renderer_host/render_widget_host_view_mac.mm

Index: content/browser/renderer_host/render_widget_host_view_mac.mm
diff --git a/content/browser/renderer_host/render_widget_host_view_mac.mm b/content/browser/renderer_host/render_widget_host_view_mac.mm
index 2a723549ec4ff2b1b9ff3f37a5c23c66a12f3a0f..392793f48d8f9faba24d93dadbe6a998532c1c68 100644
--- a/content/browser/renderer_host/render_widget_host_view_mac.mm
+++ b/content/browser/renderer_host/render_widget_host_view_mac.mm
@@ -1328,6 +1328,15 @@ void RenderWidgetHostViewMac::AcceleratedSurfaceRelease() {
 
 bool RenderWidgetHostViewMac::HasAcceleratedSurface(
       const gfx::Size& desired_size) {
+  // Update device scale factor for the IOSurface before checking if there
+  // is a match. When initially created, the IOSurface is unaware of its
+  // scale factor, which can result in compatible IOSurfaces not being used
+  // http://crbug.com/237293
+  if (compositing_iosurface_.get() &&
+      compositing_iosurface_->HasIOSurface()) {
+    compositing_iosurface_->SetDeviceScaleFactor(ScaleFactor(cocoa_view_));

[Ken Russell (switch to Gerrit), 2013/05/07 19:23:51]

It seems odd that this is done as a side-effect of calling
HasAcceleratedSurface. Is there a more obvious place this could be done?

[ccameron, 2013/05/07 19:27:36]

Yes, this I was unhappy with this too. The other place this happens is in Draw
(which also doesn't make too much sense to have side effects on resolution).

The version that I'm working on for trunk has no side effects here (but has lots
more diffs).

+  }
+
   return last_frame_was_accelerated_ &&
          compositing_iosurface_.get() &&
          compositing_iosurface_->HasIOSurface() &&