Use inner HWND for accelerated rendering on windows

chrome/browser/gpu_process_host.h

 // Copyright (c) 2010 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_BROWSER_GPU_PROCESS_HOST_H_
 #define CHROME_BROWSER_GPU_PROCESS_HOST_H_
 #pragma once
 
 #include <queue>
 
@@ skipping 79 matching lines @@
   void OnGraphicsInfoCollected(const GPUInfo& gpu_info);
 #if defined(OS_LINUX)
   void OnGetViewXID(gfx::NativeViewId id, IPC::Message* reply_msg);
 #elif defined(OS_MACOSX)
   void OnAcceleratedSurfaceSetIOSurface(
       const GpuHostMsg_AcceleratedSurfaceSetIOSurface_Params& params);
   void OnAcceleratedSurfaceBuffersSwapped(int32 renderer_id,
                                           int32 render_view_id,
                                           gfx::PluginWindowHandle window,
                                           uint64 surface_id);
+#elif defined(OS_WIN)
+  void OnCreateCompositorHostWindow(int32 renderer_id,

[jam, 2010/11/12 18:08:00]

nit: I'm curious why int32 is used, instead of just int, when both
RenderWidgetHost and RenderProcessHost define their ids as ints, and the
FromID() function which you call takes in ints?

[nduca, 2010/11/12 19:45:32]

Neat discovery. I chased this a bit deeper and it turns out that FromID
translates into a lookup into an IDMap lookup, and IDMap defines its key as
int32. Put another way, the issue is that the FromID signature is wrong.

I'm totally down with refactoring the FromID function and related. Is the right
policy to fix this within this CL, or should I do it as a separate CL?

On 2010/11/12 18:08:00, John Abd-El-Malek wrote:

[jam, 2010/11/12 20:34:41]

the IDMap can be using int32, but almost everywhere else, including where the
id's come from, uses int.  if anything, i'd prefer that the idmap uses ints as
well..

On 2010/11/12 19:45:32, nduca wrote:

[nduca, 2010/11/19 19:02:29]

So, for this CL, I will leave the IPC handlers (OnX) using the Int32 since the
IPC message definitions are explicitly sized. That way, we are at least
consistent with the guidance given here.

After studying the issue in further detail, refactoring IDMap to use ints and
adjusting all of the various code that calls into it is a pretty broad change.
While I'm happy to volunteer to normalize that, I don't think that should block
this CL.


On 2010/11/12 20:34:41, John Abd-El-Malek wrote:

[jam, 2010/11/20 00:37:00]

I feel kind of strongly that these should be ints, to match the rest of the code
that handles IDs of RenderProcessHosts and RenderViewHosts.

I agree fixing IDMap shouldn't block this change.  But it also doesn't mean that
we should use int32 until it's done, since that's being inconsistent with a lot
of existing code.

[nduca, 2010/11/22 22:37:44]

Done.

+                                    int32 render_view_id,
+                                    IPC::Message* reply_message);
+  void OnScheduleComposite(int32 renderer_id, int32 render_view_id);
 #endif
 
   void ReplyToRenderer(const IPC::ChannelHandle& channel,
                        const GPUInfo& gpu_info,
                        ResourceMessageFilter* filter);
 
   // ResourceDispatcherHost::Receiver implementation:
   virtual URLRequestContext* GetRequestContext(
       uint32 request_id,
       const ViewHostMsg_Resource_Request& request_data);
@@ skipping 10 matching lines @@
   // the GPU process, but haven't heard back about yet.
   std::queue<ChannelRequest> sent_requests_;
 
   // The pending synchronization requests we need to reply to.
   std::queue<SynchronizationRequest> queued_synchronization_replies_;
 
   DISALLOW_COPY_AND_ASSIGN(GpuProcessHost);
 };
 
 #endif  // CHROME_BROWSER_GPU_PROCESS_HOST_H_