问题
Greetings!
I'm currently porting a web browser plugin from Win32 to MacOSX. One of the features of the plugin is that when the plugin is loaded, it spawns a separate process that serves as the "engine" of the plugin and executes drawing operations into the window of the plugin (specifically, by attaching an OpenGL context to the parent process's window and executing OpenGL rendering commands into that context). We do this because the plugin is typically loaded as a thread within the browser process, so crashes in the plugin would take down the whole browser. By partitioning the 'heavy lifting' into a separate process and keeping the plugin code very slim, we can protect users against such crashes.
I'd like to preserve this child-process-renderer architecture on MacOSX, but I've heard a nasty rumor (related to the Google Chrome web browser) that MacOSX doesn't allow a process to hand access to its windows to another process. My own search in this space has been inconclusive; if anyone has any knowledge of this problem and could either provide some advice on how to accomplish this goal or a more conclusive "can't be done," it would be extremely helpful.
Thank you for your help!
回答1:
I was investigating a solution to this almost a year ago. I started a few threads on the apple mailing lists:
http://www.mail-archive.com/cocoa-dev@lists.apple.com/msg08056.html
http://www.mail-archive.com/quartzcomposer-dev@lists.apple.com/msg01878.html
http://lists.apple.com/archives/mac-opengl/2008/May/msg00099.html
I had to revert to a solution which used CGWindowListCreateImage which took a screen grab of the opengl process window and convert it to a bitmap for display in the main process window. This is far from effeicient since pixel data is transfered from video ram to system ram.
I also tried a floating window solution. The opengl process window floated above the main process window and respond to mouse movements from the main window. But I had issues with dragging lag and window z order.
You would think NSWindowSharingReadWrite would do what you require, but doumentation/examples back then were practically non existent.
But maybe things have changed in the last year. Keep me posted if you find anything new !
Good luck
JC
回答2:
Here is the overall answer received from Apple's development team.
There is essentially no way to do this in MacOSX 10.5 and earlier that is as clean as attaching an OpenGL rendering context to another process's window. The hacks people have developed may be the best solutions in those cases.
The closest thing we have in MacOS 10.6 is the IOSurface system; using that in 10.6 seems to be the cleanest solution. If you want clicks in the rendered-to process to be intercepted by the rendering process, you'll have to bundle up the events yourself and pass them to the rendering process using whatever method you find most appropriate.
More information on IOSurface could be found in this StackOverflow entry
回答3:
A window in one process can be written to by another process, seemingly if the NSWindowSharingType is set to NSWindowSharingReadWrite. That was added in Leopard. Note that I haven't used this myself, but I would say that it at least removes the "can't be done" obstacle for you ;-)
来源：https://stackoverflow.com/questions/583202/mac-os-x-can-one-process-render-to-another-processs-window