multi-process hosted browser window on Mac/Linux

[Marshall Greenblatt]

Hi All,

I'm exploring ways to use the existing Chromium multi-process architecture for embedded browser controls. One option that I'm considering is embedding the complete browser window (minus the application frame) as a separate process parented to a host application window. One advantage that I see to this approach versus integrating the browser window in-process is that I can maintain rendering performance by not having to integrate directly with the host application message loop. On Windows this is relatively straightforward because I can have the browser process create its window as a child of another process' window. On Mac (and maybe Linux?) this seems more problematic. According to the Mac Plugins document (http://www.chromium.org/developers/design-documents/mac-plugins) Chromium uses a combination of "DYLD_INSERT_LIBRARIES to hook Carbon window creation and activation calls, and swizzling to hook Cocoa window creation and activation calls" in order to host out-of-process windowed plugins. This leads me to a few questions:

1. Is this same technique likely to work for hosting the browser window out-of-process on Mac?
2. What would be the best technique, if any, for hosting the browser window out-of-process on Linux?
3. Is hosting the browser window in this manner likely to interfere with Chromium's ability to host out-of-process windowed plugins on Mac or Linux?

Any related guidance would also be appreciated.

Thanks,
Marshall

[Marshall Greenblatt]

[+chromium-dev]

Hi Nat,

On Fri, Aug 19, 2011 at 12:01 PM, Nat Duca <nd...@google.com> wrote:

I can't speak to the overall challenge, but if you decide to attack this, keep in mind that Chrome has two rendering paths --- software and gpu accelerated. You'll either need to disable gpu rendering :'( or figure out how to do that as well.

From reading the docs it looks like the GPU process renders directly to the browser window handle/GL context. It seems like most of the windowed plugin "hacks" on Mac are related to positioning/activating the plugin window correctly relative to the host window. Would the GPU process be able to render directly to the out-of-process browser window on Mac (similar to running the Chromium browser stand-alone) or would the rendering need to somehow be managed through the host application?

Thanks,
Marshall
 

--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

[Evan Martin]

On Fri, Aug 19, 2011 at 8:15 AM, Marshall Greenblatt
<magree...@gmail.com> wrote:

I dunno much about Mac, but on Linux X itself is designed around
embedding windows between processes; for example the window frame is
typically a different process than the body of the window. I don't
see any obvious problems with your idea, though getting focus right is
often an issue. See
http://standards.freedesktop.org/xembed-spec/xembed-spec-latest.html
for a discussion of the kinds of API you need beyond a "stuff this
window in that one" approach. For Chrome, Xembed is implemented by
Gtk's GtkPlug and GtkSocket, so it might be possible to put a
TabContents inside a GtkPlug and have the rest just work.

[Nico Weber]

Hi Marshall,

I don't think OS X supports cross-process window hosting.

Nico

On Fri, Aug 19, 2011 at 9:44 AM, Marshall Greenblatt
<magree...@gmail.com> wrote:
> [+chromium-dev]
>
> Hi Nat,
>
> On Fri, Aug 19, 2011 at 12:01 PM, Nat Duca <nd...@google.com> wrote:
>>
>> I can't speak to the overall challenge, but if you decide to attack this,
>> keep in mind that Chrome has two rendering paths --- software and gpu
>> accelerated. You'll either need to disable gpu rendering :'( or figure out
>> how to do that as well.
>
> From reading the docs it looks like the GPU process renders directly to the
> browser window handle/GL context. It seems like most of the windowed plugin
> "hacks" on Mac are related to positioning/activating the plugin window
> correctly relative to the host window. Would the GPU process be able to
> render directly to the out-of-process browser window on Mac (similar to
> running the Chromium browser stand-alone) or would the rendering need to
> somehow be managed through the host application?

There are no windowed plugins on mac, they're all windowless.

[Marshall Greenblatt]

Very cool, thanks Evan.

[Marshall Greenblatt]

On Fri, Aug 19, 2011 at 12:59 PM, Nico Weber <tha...@chromium.org> wrote:

Hi Marshall,

I don't think OS X supports cross-process window hosting.

This makes me sad. It sounds like the techniques described on the "Mac Plugins" page were implemented at one time. Do you know why they were abandoned?
 

Nico

On Fri, Aug 19, 2011 at 9:44 AM, Marshall Greenblatt
<magree...@gmail.com> wrote:
> [+chromium-dev]
>
> Hi Nat,
>
> On Fri, Aug 19, 2011 at 12:01 PM, Nat Duca <nd...@google.com> wrote:
>>
>> I can't speak to the overall challenge, but if you decide to attack this,
>> keep in mind that Chrome has two rendering paths --- software and gpu
>> accelerated. You'll either need to disable gpu rendering :'( or figure out
>> how to do that as well.
>
> From reading the docs it looks like the GPU process renders directly to the
> browser window handle/GL context. It seems like most of the windowed plugin
> "hacks" on Mac are related to positioning/activating the plugin window
> correctly relative to the host window. Would the GPU process be able to
> render directly to the out-of-process browser window on Mac (similar to
> running the Chromium browser stand-alone) or would the rendering need to
> somehow be managed through the host application?

There are no windowed plugins on mac, they're all windowless.

Is this a recent(ish) development? Should we mark http://www.chromium.org/developers/design-documents/mac-plugins as deprecated?
 

[Nico Weber]

On Fri, Aug 19, 2011 at 10:09 AM, Marshall Greenblatt
<magree...@gmail.com> wrote:
> On Fri, Aug 19, 2011 at 12:59 PM, Nico Weber <tha...@chromium.org> wrote:
>>
>> Hi Marshall,
>>
>> I don't think OS X supports cross-process window hosting.
>
> This makes me sad. It sounds like the techniques described on the "Mac
> Plugins" page were implemented at one time. Do you know why they were
> abandoned?

(below)

No, I think that page is up-to-date. "Normal" plugins (say, Flash on
YouTube) render into a backbuffer that is then drawn into the renderer
backing store (or drawn directly by the browser, in the case of
plugins using the CoreAnimation drawing model) – the normal windowless
plugin drawing path.

What that page above means (I think, I'm not an expert here) is if a
plugin wants to open a window (which almost never happens in
practice), then in the plugin process we intercept that call and open
the window in the browser process. There's no cross-process window
hosting going on here, the window lives in the browser process, and
the window management calls done by the plugin are ipc'd to the
browser process.

HTH,
Nico

[Marshall Greenblatt]

OK, that makes sense. Thanks for the clarification :-).
 

[Stuart Morgan]

Le 19 août 2011 18:44, Marshall Greenblatt <magree...@gmail.com> a écrit :
> It seems like most of the windowed plugin
> "hacks" on Mac are related to positioning/activating the plugin window
> correctly relative to the host window.

Those hacks are only there because a very common operation these
plugins need to do is to convert global screen coordinates (which is
what old-style plugins on the Mac get for all events) to local window
coordinates, and then from there to plugin-relative coordinates. In
order for that to work, the window has to be (or at least appear to
be, in those calls) in the right place. The window itself is not
actually visible.

We considered trying to have the window visible in order to get good
performance of legacy plugins (vs. the current *really* slow method of
scraping the window contents), but it was very problematic, and we
decided it was not worth the effort given that there are fewer and
fewer plugins that haven't updated.

A more compelling cautionary tale is Apple's Java Plugin2. The early
shipped versions of that plugin did in fact position a window from
another process in the right place. It had a number of issues, and
they eventually abandoned that approach in favor of adapting it to
standard NPAPI. If Apple (with full access to all the source, SPI,
etc.) decided that using NPAPI (even with all the drawing and event
complications that entails; NPAPI is not noted for its ease-of-use)
was easier than trying to seamlessly host an out-of-process window
directly, it's a pretty good bet that you don't want to go down that
path.

-Stuart

[nono....@gmail.com]

@Stuart,

We considered trying to have the window visible in order to get good
performance of legacy plugins (vs. the current *really* slow method of
scraping the window contents), but it was very problematic, and we
decided it was not worth the effort given that there are fewer and
fewer plugins that haven't updated.

I know this thread is a couple of years old but, still, your help could be highly welcome:

Is there anything left from this early attempt to "have the window visible"?

Do you have a short list of "very problematic" problems that have been raised by this method?

I ask because even if this solution is not good, it could be good enough for what I try to do (embed an old app into a new one).

A more compelling cautionary tale is Apple's Java Plugin2. The early
shipped versions of that plugin did in fact position a window from
another process in the right place. 

Hopefully, if it has been a fair enough trick for Apple to release such a version of the Java Plugin then maybe I can keep dreaming ;-)

Thanks for your help,

Arnaud.