Deliver IPC messages together with SwapCompositorFrame

cc/output/compositor_frame_metadata.h

 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #ifndef CC_OUTPUT_COMPOSITOR_FRAME_METADATA_H_
 #define CC_OUTPUT_COMPOSITOR_FRAME_METADATA_H_
 
 #include <vector>
 
 #include "cc/base/cc_export.h"
@@ skipping 23 matching lines @@
   float min_page_scale_factor;
   float max_page_scale_factor;
 
   // Used to position the Android location top bar and page content, whose
   // precise position is computed by the renderer compositor.
   gfx::Vector2dF location_bar_offset;
   gfx::Vector2dF location_bar_content_translation;
   float overdraw_bottom_height;
 
   std::vector<ui::LatencyInfo> latency_info;
+  // Payload associated with this frame.
+  std::vector<IPC::Message> payload;

[mkosiba (inactive), 2014/05/06 22:30:33]

metadata seems to be the most convenient place for hacking but I imagine we want
this to liv in SwapCompositorFrame directly?

[piman, 2014/05/07 01:21:46]

I don't think we want to make cc depend on IPC.

I think we can relatively easily have it on the message, if the RWSwapPromise
has a way to get to the CompositorOutputSurface, since DidSwap is called before
the actual swap (the CompositorOutputSurface can stash whatever info from the
RWSwapPromise, and include it with the SwapCompositorFrame IPC)

[mkosiba (inactive), 2014/05/07 18:27:20]

true. The other reason I'm gravitating towards metadata is because the WebView
synchronous compositor doesn't use SwapCompositorFrame (and does use metadata)
but I could equally well add a bit of extra plumbing to the synchronous CC that
replicates whatever CompositorOutputSurface does).

 };
 
 }  // namespace cc
 
 #endif  // CC_OUTPUT_COMPOSITOR_FRAME_METADATA_H_