Add optimization for CHROMIUM_subscribe_uniform extension.

content/browser/renderer_host/render_widget_host_impl.cc

Index: content/browser/renderer_host/render_widget_host_impl.cc
diff --git a/content/browser/renderer_host/render_widget_host_impl.cc b/content/browser/renderer_host/render_widget_host_impl.cc
index 54e59de423ca3e3298a7c2fa40f772112b07bc2d..6e248e6e648a0bdd541fc451f910448fe62bdbdc 100644
--- a/content/browser/renderer_host/render_widget_host_impl.cc
+++ b/content/browser/renderer_host/render_widget_host_impl.cc
@@ -183,7 +183,6 @@ RenderWidgetHostImpl::RenderWidgetHostImpl(RenderWidgetHostDelegate* delegate,
       pending_mouse_lock_request_(false),
       allow_privileged_mouse_lock_(false),
       has_touch_handler_(false),
-      subscribe_uniform_enabled_(false),
       next_browser_snapshot_id_(1),
       weak_factory_(this) {
   CHECK(delegate_);
@@ -233,10 +232,6 @@ RenderWidgetHostImpl::RenderWidgetHostImpl(RenderWidgetHostDelegate* delegate,
         base::Bind(&RenderWidgetHostImpl::RendererIsUnresponsive,
                    weak_factory_.GetWeakPtr())));
   }
-
-  subscribe_uniform_enabled_ =
-      base::CommandLine::ForCurrentProcess()->HasSwitch(
-          switches::kEnableSubscribeUniformExtension);
 }
 
 RenderWidgetHostImpl::~RenderWidgetHostImpl() {
@@ -902,17 +897,11 @@ void RenderWidgetHostImpl::ForwardMouseEventWithLatencyInfo(
 
   // Pass mouse state to gpu service if the subscribe uniform
   // extension is enabled.
-  // TODO(orglofch): Only pass mouse information if one of the GL Contexts
-  // is subscribed to GL_MOUSE_POSITION_CHROMIUM
-  if (subscribe_uniform_enabled_) {
+  if (process_->SubscribeUniformEnabled()) {
     gpu::ValueState state;
     state.int_value[0] = mouse_event.x;
     state.int_value[1] = mouse_event.y;
-    GpuProcessHost::SendOnIO(
-        GpuProcessHost::GPU_PROCESS_KIND_SANDBOXED,
-        CAUSE_FOR_GPU_LAUNCH_NO_LAUNCH,
-        new GpuMsg_UpdateValueState(
-            process_->GetID(), GL_MOUSE_POSITION_CHROMIUM, state));
+    process_->SendUpdateValueState(GL_MOUSE_POSITION_CHROMIUM, state);

[piman, 2014/12/12 01:47:38]

So, you still have the problem that the RPH receives updates from separate RWH
that will end up impacting all RenderWidgets associated with that process (move
the mouse in renderer A, you get updates to values in renderer B).

Really the way to solve that is to have each RW request updates for its own
routing id, and keeping those separate (i.e. not merge the value state map
between all command buffers in a channel, or maybe tag the subscription with the
RW routing id?).

I'm fine if it's a follow up, but can you add a TODO / file a bug?

[orglofch, 2014/12/12 02:17:58]

I guess I'm missing an understanding of what a RW maps to physically. For
example, can we have multiple RWH tiled in a single window such that they're
functionally different windows? If so does the GL context know which RW it's in
so it can communicate which pending_state to use? Otherwise we should simply use
the most recent value_states.

Is there something in the Gpu Process which maps to a RWH the same way RPH maps
to GpuChannel?

I've added the TODO and I'll try to follow up this weekend.

[piman, 2014/12/12 02:41:40]

a RW is the contents of a tab. You can have several RW per renderer process
(RPH), e.g. if they're from the same origin. Those tabs might be in different
windows.

The problem about which RW the context corresponds to is that it can change. For
example in JavaScript you can move the canvas element between related documents
in the same origin (e.g. opened by window.open), or, actually, remove it from
all DOMs while still having the context, i.e. the context doesn't correspond to
any RW at all.

So even at the API level in webgl, "subscribing" to the mouse position doesn't
completely make sense unless you give a document the mouse position is relative
to.
Or you use an absolute mouse position (i.e. screen-relative instead of
page-relative), in which case the value would be the same regardless of which RW
it comes from (that's what I originally thought the API would give you).

[orglofch, 2014/12/12 02:58:55]

Ok I see what you're saying, I was confused because this didn't seem to make
sense with regards to the current API. 

Seems like this change is more substantial than I had originally thought so I'll
create a tracking bug.

   }
 }