Let DelegateFrameHost in Mac and Android use correct FrameSinkId during creation

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 c91614f5c60f505661f68f3390315a215913abfc..593ba3f9ae8bff3060f4b1057dbd3731951352f4 100644
--- a/content/browser/renderer_host/render_widget_host_view_mac.mm
+++ b/content/browser/renderer_host/render_widget_host_view_mac.mm
@@ -468,8 +468,19 @@ RenderWidgetHostViewMac::RenderWidgetHostViewMac(RenderWidgetHost* widget,
   [cocoa_view_ setLayer:background_layer_];
   [cocoa_view_ setWantsLayer:YES];
 
-  browser_compositor_.reset(new BrowserCompositorMac(
-      this, this, render_widget_host_->is_hidden(), [cocoa_view_ window]));
+  // GuestViews have two RenderWidgetHostViews and so we need to make sure

[boliu, 2017/01/26 00:14:39]

can you explain a bit how this works? will both RWHVs have is_guest_view_hack_
set to true?

[xlai (Olivia), 2017/01/26 15:56:11]

I copied this comment and the same piece of code from
https://cs.chromium.org/chromium/src/content/browser/renderer_host/render_wid....
is_guest_view_hack is usually false.

The code here is just make Mac platform to behave as same as non-Mac platform.
Otherwise the use of frame sink id in my another patch
https://codereview.chromium.org/2644653003/ is crashing on Mac platform only.

From what I know it is part of the project in MUS team to update frame sink id
for two different scenarios: when the view acts as platform view hack for a
RenderWidgetHostViewGuest, or when it is
not. fsamuel@: Do you mind explaining in more details to boliu@ on why this is
necessary? 

[Fady Samuel, 2017/01/26 16:06:36]

guest_view_hack a flag used for the BrowserPlugin implementation of guestview.
Fortunately that code going away soon (within a quarter I guess) as the
GuestView team is transitioning to the new OOPIF architecture.

Android doesn't have <webview> in WebUI or Chrome Apps so this is a non-issue on
that platform.

[boliu, 2017/01/26 19:24:46]

Same question here, how do we know AllocateFrameSinkId won't collide with
process/routing id?

[xlai (Olivia), 2017/01/26 20:50:21]

Mac is using GPUProcessTransportFactory so it's same as Aura: 0 is the browser
ID and renderer processes have non-zero IDs so there will not be conflicts.

+  // we don't have FrameSinkId collisions.
+  ImageTransportFactory* factory = ImageTransportFactory::GetInstance();
+  cc::FrameSinkId frame_sink_id =
+      is_guest_view_hack_
+          ? factory->GetContextFactoryPrivate()->AllocateFrameSinkId()
+          : cc::FrameSinkId(base::checked_cast<uint32_t>(
+                                render_widget_host_->GetProcess()->GetID()),
+                            base::checked_cast<uint32_t>(
+                                render_widget_host_->GetRoutingID()));
+  browser_compositor_.reset(
+      new BrowserCompositorMac(this, this, render_widget_host_->is_hidden(),
+                               [cocoa_view_ window], frame_sink_id));
 
   display::Screen::GetScreen()->AddObserver(this);