compositor-worker: cc->blink mutation plumbing

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 ddd60cb9e6f1a7dace2cb3c442c7f8a78ed5de40..acc43cb8a2fad5d1b9464a93ea44e6d1ad4f37b0 100644
--- a/content/renderer/render_widget.cc
+++ b/content/renderer/render_widget.cc
@@ -1000,6 +1000,13 @@ void RenderWidget::ApplyViewportDeltas(
                                   top_controls_delta);
 }
 
+void RenderWidget::ApplyMutations(const cc::LayerTreeMutations& mutations) {
+  TRACE_EVENT0(TRACE_DISABLED_BY_DEFAULT("compositor-worker"),
+               "RenderWidget::ApplyMutations");
+  webwidget_->applyCompositorMutations(
+      static_cast<const blink::WebCompositorMutations&>(mutations));

[piman, 2016/01/29 01:50:08]

This bothers me a little, because I have no way of knowing whether the
static_cast is safe (I guess the code that fills
BeginMainFrameAndCommitState::mutations is not in this CL).

Taking a step back, if I understand where this is going, LayerTreeMutations
doesn't really have anything to do with cc - it's just some placeholder type so
that some data can flow backwards (impl->main) through the commit flow, but cc
never cares about the data itself.

In a way, it's the pendant of SwapPromise (just works the other way around). So
maybe we could introduce a BeginMainFramePromise or something like that, with a
virtual DidBeginMainFrame() - or maybe even more simply a BeginMainFrameCallback
that could be stashed on the impl thread, and executed on the main thread? This
would give us back the type safety, because the callback could encode the
concrete type in the curried data (or the concrete implementation of
BeginMainFramePromise would contain the concrete data). It could also be reused
for other purpose (e.g. scroll/viewport deltas, maybe input events, etc.).

WDYT?

+}
+
 void RenderWidget::BeginMainFrame(double frame_time_sec) {
   webwidget_->beginFrame(frame_time_sec);
 }