From agl. Cleaned up version of issue 19046.

POSIX: bitmap data on the wire

On Windows, when drawing a given rect in the renderer, we allocate memory for the bitmap, render and send a shared memory handle across IPC. In the browser, we bitblit the shared memory to the backing store and draw it to the screen.

In the long term, on Linux, we want the backingstore to be shared with both X and the renderer. The renderer then draws directly to that store, sends an IPC to the browser and the browser sends a message to X to bitblit to the display. Since only cache a few backing stores we'll need messages from the browser to tell the renderer to attach and detatch from shared memory regions as they get created and evicted.

In the short term, however, to get something that works, we make a BitmapWireData typedef. This will be a shared memory region on Windows, as before, and on POSIX we'll be sending the bitmap data over the wire. Obviously this'll be pretty slow but it'll work sooner.
Review URL: http://codereview.chromium.org/19491

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9065 0039d316-1c4b-4281-b951-d872f2087c98

3 files changed, 70 insertions, 16 deletions

diff --git a/chrome/common/bitmap_wire_data.h b/chrome/common/bitmap_wire_data.h
new file mode 100644
index 0000000..c4e1edd
--- /dev/null
+++ b/chrome/common/bitmap_wire_data.h
@@ -0,0 +1,35 @@
+// Copyright (c) 2006-2008 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 CHROME_COMMON_BITMAP_WIRE_DATA_H_
+#define CHROME_COMMON_BITMAP_WIRE_DATA_H_
+
+#if defined(OS_POSIX)
+class SkBitmap;
+#endif
+
+// BitmapWireData is the type of the bitmap data which is carried from renderer
+// to browser over the wire.
+
+#if defined(OS_WIN)
+
+// On Windows, the bitmap data is carried out-of-band in a shared memory
+// segment. This is the handle to the shared memory. These handles are valid
+// only in the context of the renderer process.
+// TODO(agl): get a clarification on that last sentence. It doesn't make any
+// sense to me
+typedef HANDLE BitmapWireData;
+
+#elif defined(OS_POSIX)
+
+// On POSIX, we currently serialise the bitmap data over the wire. This will
+// change at some point when we too start using shared memory, but we wish to
+// use shared memory in a different way so this is a temporary work-around.
+// TODO(port): implement drawing with shared backing stores and replace this
+//   with an IPC no-op type.
+typedef SkBitmap BitmapWireData;
+
+#endif  // defined(OS_WIN)
+
+#endif  // CHROME_COMMON_BITMAP_WIRE_DATA_H_
diff --git a/chrome/common/render_messages.h b/chrome/common/render_messages.h
index dd756d7..95c7e6d 100644
--- a/chrome/common/render_messages.h
+++ b/chrome/common/render_messages.h
@@ -10,8 +10,10 @@
 #include <map>
 
 #include "base/basictypes.h"
+#include "base/gfx/native_widget_types.h"
 #include "base/ref_counted.h"
 #include "base/shared_memory.h"
+#include "chrome/common/bitmap_wire_data.h"
 #include "chrome/common/filter_policy.h"
 #include "chrome/common/ipc_message.h"
 #include "chrome/common/ipc_message_utils.h"
@@ -33,6 +35,10 @@
 #include "webkit/glue/webpreferences.h"
 #include "webkit/glue/webview_delegate.h"
 
+#if defined(OS_POSIX)
+#include "skia/include/SkBitmap.h"
+#endif
+
 // Parameters structure for ViewMsg_Navigate, which has too many data
 // parameters to be reasonably put in a predefined IPC message.
 struct ViewMsg_Navigate_Params {
@@ -190,13 +196,9 @@ struct ViewHostMsg_PaintRect_Flags {
   }
 };
 
-#if defined(OS_WIN)
-// TODO(port): Make these structs portable.
-
 struct ViewHostMsg_PaintRect_Params {
-  // The bitmap to be painted into the rect given by bitmap_rect.  Valid only
-  // in the context of the renderer process.
-  base::SharedMemoryHandle bitmap;
+  // The bitmap to be painted into the rect given by bitmap_rect.
+  BitmapWireData bitmap;
 
   // The position and size of the bitmap.
   gfx::Rect bitmap_rect;
@@ -228,9 +230,8 @@ struct ViewHostMsg_PaintRect_Params {
 // Parameters structure for ViewHostMsg_ScrollRect, which has too many data
 // parameters to be reasonably put in a predefined IPC message.
 struct ViewHostMsg_ScrollRect_Params {
-  // The bitmap to be painted into the rect exposed by scrolling.  This handle
-  // is valid only in the context of the renderer process.
-  base::SharedMemoryHandle bitmap;
+  // The bitmap to be painted into the rect exposed by scrolling.
+  BitmapWireData bitmap;
 
   // The position and size of the bitmap.
   gfx::Rect bitmap_rect;
@@ -248,7 +249,6 @@ struct ViewHostMsg_ScrollRect_Params {
   // New window locations for plugin child windows.
   std::vector<WebPluginGeometry> plugin_window_moves;
 };
-#endif  // defined(OS_WIN)
 
 // Parameters structure for ViewMsg_UploadFile.
 struct ViewMsg_UploadFile_Params {
@@ -967,9 +967,6 @@ struct ParamTraits<ViewHostMsg_ContextMenu_Params> {
   }
 };
 
-#if defined(OS_WIN)
-// TODO(port): Make these messages portable.
-
 // Traits for ViewHostMsg_PaintRect_Params structure to pack/unpack.
 template <>
 struct ParamTraits<ViewHostMsg_PaintRect_Params> {
@@ -1078,7 +1075,6 @@ struct ParamTraits<WebPluginGeometry> {
     l->append(L")");
   }
 };
-#endif  // defined(OS_WIN)
 
 // Traits for ViewMsg_GetPlugins_Reply structure to pack/unpack.
 template <>
@@ -1738,6 +1734,31 @@ struct ParamTraits<ModalDialogEvent> {
   }
 };
 
+#if defined(OS_POSIX)
+
+// TODO(port): this shouldn't exist. However, the plugin stuff is really using
+// HWNDS (NativeView), and making Windows calls based on them. I've not figured
+// out the deal with plugins yet.
+template <>
+struct ParamTraits<gfx::NativeView> {
+  typedef gfx::NativeView param_type;
+  static void Write(Message* m, const param_type& p) {
+    NOTIMPLEMENTED();
+  }
+
+  static bool Read(const Message* m, void** iter, param_type* p) {
+    NOTIMPLEMENTED();
+    *p = NULL;
+    return true;
+  }
+
+  static void Log(const param_type& p, std::wstring* l) {
+    l->append(StringPrintf(L"<gfx::NativeView>"));
+  }
+};
+
+#endif  // defined(OS_POSIX)
+
 }  // namespace IPC
 
 #endif  // CHROME_COMMON_RENDER_MESSAGES_H_
diff --git a/chrome/common/render_messages_internal.h b/chrome/common/render_messages_internal.h
index 732c730..149dd53 100644
--- a/chrome/common/render_messages_internal.h
+++ b/chrome/common/render_messages_internal.h
@@ -613,7 +613,6 @@ IPC_BEGIN_MESSAGES(ViewHost, 2)
                               navigating to a POST again and we're going to
                               show the POST interstitial */ )
 
-#if defined(OS_WIN)
   // Sent to paint part of the view.  In response to this message, the host
   // generates a ViewMsg_PaintRect_ACK message.
   IPC_MESSAGE_ROUTED1(ViewHostMsg_PaintRect,
@@ -623,7 +622,6 @@ IPC_BEGIN_MESSAGES(ViewHost, 2)
   // generates a ViewMsg_ScrollRect_ACK message.
   IPC_MESSAGE_ROUTED1(ViewHostMsg_ScrollRect,
                       ViewHostMsg_ScrollRect_Params)
-#endif
 
   // Acknowledges receipt of a ViewMsg_HandleInputEvent message.
   // Payload is a WebInputEvent::Type which is the type of the event, followed