Right, that's actually what I'm suggesting we aim for. When the renderer needs to ask questions about the HWND associated with a RenderView, it can just ask questions of the RenderViewHost. The RenderViewHost can use its HWND to answer the questions. The story is not quite that simple of course since we need to answer those IPCs on a background thread and the RenderViewHost only runs on the main UI thread. Hence, we need the map that the IO thread can interrogate.
-Darin On Mon, May 4, 2009 at 1:37 PM, Amanda Walker <[email protected]> wrote: > Hmm. Would it be even cleaner for nothing but the plugin host process > to care about the NativeViewId, since it's what has to provide it to > the plugin via NPAPI? For everything else, either we're windowless > and just shipping bitmaps around (no need for a window reference at > all except to keep the plugin happy) or we're windowed and just need > an ID that the plugin process can map to a "real" window reference. > I'm not clear on why the renderer needs to track it at all (though the > browser might, for things like the scrolling performance reparenting > stuff) > > --Amanda > > On Mon, May 4, 2009 at 1:57 PM, Darin Fisher <[email protected]> wrote: > > Yes, seems like it should be all around cleaner too :) > > -Darin > > > > On Mon, May 4, 2009 at 9:43 AM, Adam Barth <[email protected]> wrote: > >> > >> I see. In this design, we would translate render_view_ids to > >> NativeViewIds on the IO thread instead of round-tripping the UI > >> thread. That seems workable without changing the semantics of the IPC > >> messages. > >> > >> Adam > >> > >> > >> On Sun, May 3, 2009 at 10:31 PM, Darin Fisher <[email protected]> > wrote: > >> > We should definitely eliminate the need for the renderer to refer > >> > directly > >> > to its native view. I have been gradually working in this direction. > >> > Instead of sending view ids around, it should be enough to reference > the > >> > render_view_id (i.e., routing_id). We don't need to graph this > mapping > >> > onto > >> > RendererSecurityPolicy (in fact that would definitely overload the > >> > meaning > >> > of renderer security policy). Instead, we should probably just build > a > >> > new > >> > mapping from render_view_id to object. Perhaps that mapping system > >> > could be > >> > used by the RendererSecurityPolicy to store security bits associated > >> > with > >> > the render view so that we don't need to have two maps. > >> > I am already close to eliminating the NativeViewID parameters in the > >> > WebKit > >> > API. > >> > -Darin > >> > > >> > On Sun, May 3, 2009 at 7:14 PM, Adam Barth <[email protected]> > wrote: > >> >> > >> >> Currently we have a handful of renderer -> browser IPC messages that > >> >> contain gfx::NativeViewIds: > >> >> > >> >> ViewHostMsg_GetWindowRect > >> >> ViewHostMsg_GetScreenInfo > >> >> ViewHostMsg_GetRootWindowRect > >> >> ViewHostMsg_GetRootWindowResizerRect > >> >> ViewHostMsg_ScriptedPrint > >> >> > >> >> These make me sad because the render could ask about random > >> >> NativeViewIds (HWNDs) that have nothing to do with that renderer. > >> >> There are two approaches we can use to correct these infelicities: > >> >> > >> >> 1) Change these message to avoid sending NativeViewIds. This seems > >> >> possible, but some unknown amount of work. > >> >> > >> >> 2) Add more state to RendererSecurityPolicy that tracks which > >> >> NativeViewIds each renderer is permitted to interrogate. > >> >> > >> >> I'm inclined to go with (2), but I wanted to check in with Mac / > Linux > >> >> folks to make sure this makes sense for those platforms too. > >> >> > >> >> Thoughts? > >> >> > >> >> Adam > >> >> > >> >> > >> > > >> > > >> > > > >> > > > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
