diff options
| author | thestig@chromium.org <thestig@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2009-02-03 02:11:48 +0000 |
|---|---|---|
| committer | thestig@chromium.org <thestig@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2009-02-03 02:11:48 +0000 |
| commit | 661eb9d1aa5468b984a92e66937432d881f70427 (patch) | |
| tree | 81bf2b132ac6c7b05b04598e875552819222bb73 /chrome/common/render_messages.h | |
| parent | 99aa2dbf4962fb1a4a52a3eae9bb51ad3113b7be (diff) | |
| download | chromium_src-661eb9d1aa5468b984a92e66937432d881f70427.zip chromium_src-661eb9d1aa5468b984a92e66937432d881f70427.tar.gz chromium_src-661eb9d1aa5468b984a92e66937432d881f70427.tar.bz2 | |
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
Diffstat (limited to 'chrome/common/render_messages.h')
| -rw-r--r-- | chrome/common/render_messages.h | 49 |
1 files changed, 35 insertions, 14 deletions
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_ |