Delete background tab IOSurfaces on Mac.

content/common/view_messages.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.
 
 // IPC messages for page rendering.
 // Multiply-included message file, hence no include guard.
 
 #include "base/process.h"
 #include "base/shared_memory.h"
 #include "content/common/content_export.h"
@@ skipping 481 matching lines @@
   // The scroll offset of the render view.
   IPC_STRUCT_MEMBER(gfx::Point, scroll_offset)
 
   // The regions of the bitmap (in view coords) that contain updated pixels.
   // In the case of scrolling, this includes the scroll damage rect.
   IPC_STRUCT_MEMBER(std::vector<gfx::Rect>, copy_rects)
 
   // The size of the RenderView when this message was generated.  This is
   // included so the host knows how large the view is from the perspective of
   // the renderer process.  This is necessary in case a resize operation is in
-  // progress.
+  // progress. If auto-resize is enabled, this should update the corresponding
+  // view size.
   IPC_STRUCT_MEMBER(gfx::Size, view_size)
 
   // New window locations for plugin child windows.
   IPC_STRUCT_MEMBER(std::vector<webkit::npapi::WebPluginGeometry>,
                     plugin_window_moves)
 
+  // GPU SwapBuffers params:
+  IPC_STRUCT_MEMBER(int32, gpu_surface_id)
+  IPC_STRUCT_MEMBER(uint64, gpu_surface_handle)
+  IPC_STRUCT_MEMBER(int32, gpu_route_id)
+  IPC_STRUCT_MEMBER(int32, gpu_process_host_id)

[piman, 2012/04/18 20:02:00]

Ok, these fields look completely arbitrary.
In GpuProcessHost, you're creating this with setting no field except those 4.
For a message coming from the renderer you set all the fields except those 4.
In RenderWidgetHostImpl::OnMsgUpdateRect you have a big if (gpu_surface_id) {
do_something(); } else { do_something_different(); }

It really calls for 2 separate messages.

RenderWidgetHelper doesn't actually care if the msg is a ViewHostMsg_UpdateRec
or not, it always goes through the dispatch mechanism.

I'll argue, why not simply forward the
GpuHostMsg_AcceleratedSurfaceBuffersSwapped message through that mechanism?

[jbates, 2012/04/18 23:01:58]

I think that would be cleaner with this CL, but it would take us farther from
the goal of merging UpdateRect and BuffersSwapped (this CL is a stepping stone
towards that). If we eventually merge the two, then even if this UpdateRect is a
SwapBuffers, it would still contain the rest of the UpdateRect data from the
renderer and the OnMsgUpdateRect code would execute in both cases.

[piman, 2012/04/18 23:32:22]

I think we should do that change (or whatever is required then) once we get to
that.
For the merging, I don't think you need to merge the GPU-initiated and the
Renderer-initiated messages, they just need to carry some common data (which can
be extracted in a common struct).

[jbates, 2012/04/19 01:24:18]

Sounds good, I'll put up a new CL tomorrow-ish.

+
   // The following describes the various bits that may be set in flags:
   //
   //   ViewHostMsg_UpdateRect_Flags::IS_RESIZE_ACK
   //     Indicates that this is a response to a ViewMsg_Resize message.
   //
   //   ViewHostMsg_UpdateRect_Flags::IS_RESTORE_ACK
   //     Indicates that this is a response to a ViewMsg_WasRestored message.
   //
   //   ViewHostMsg_UpdateRect_Flags::IS_REPAINT_ACK
   //     Indicates that this is a response to a ViewMsg_Repaint message.
@@ skipping 1489 matching lines @@
                     int  /* automation_id */)
 
 // Sent to the browser when the renderer detects it is blocked on a pepper
 // plugin message for too long. This is also sent when it becomes unhung
 // (according to the value of is_hung). The browser can give the user the
 // option of killing the plugin.
 IPC_MESSAGE_ROUTED3(ViewHostMsg_PepperPluginHung,
                     int /* plugin_child_id */,
                     FilePath /* path */,
                     bool /* is_hung */)