Re: Electrolysis update: out-of-process plugins and more

On 15-Jun-09, at 2:05 PM, Chris Jones wrote:
> We have a complete short-term story for plugin graphics on X11.  
> Windowed plugins are very easy to support, as X windows are  
> identified with cross-process XID's; we need only to create the  
> window in the Gecko process and ship the ID across to the plugin.   
> Windowless plugins are more difficult to support, but we can reuse  
> som work done for Hildon; essentially, we create a window for the  
> windowless plugins and create a surface within that window for the  
> plugin to draw to, but use Xdamage and Xcomposite to composite the  
> Gecko window with the plugin's window. (Graphics folks, if this is a  
> bad summary of this technique, please correct me.)  Ben Turner will  
> likely be working on plugin graphics for Windows, but we're not yet  
> sure of our approach to plugin graphics for OS X.

For the record, here's my rough understanding of what WebKit does for  
out of process plugins on Snow Leopard.

The implementation is in WebKit/mac/Plugins/Hosted. Unfortunately, the  
WebKit tree does not seem to include the client code???

Overview and background
- All of the IPC is done using mach ports
- They have a client (presumably the plugin process) and a host
- CoreAnimation (CA) is a new UI API introduced in Leopard and on the  
iPhone.
- A CALayer is a high level abstraction of a backing store. The  
backing store is usually in video ram and CALayers are usually drawn  
using a textured quads
- CARenderer is an object responsible for drawing a hierarchy of layers.

On host initialization
- The host manager (NetscapePluginHostManager.mm) creates a render  
server using WKInitializeRenderServer() which returns a renderServerPort
- This renderServerPort is passed into _WKPHCheckInWithPluginHost(),  
however I'm not sure what that does or where it's implemented.

On plugin initialization (WebHostedNetscapePluginView.mm:createPlugin)
- instantiatePlugin() is called which returns a renderContextID and a  
useSoftwareRenderer flag
- the renderContextID is presumably associated with the RenderServer  
created earlier

- if (useSoftwareRenderer) then  
WKSoftwareCARendererCreate(renderContextID)
   - the softwareRenderer draws in drawRect() using  
WKSoftwareCARendererRender()
   - I'm not sure what the advantage of using CoreAnimation here is,  
because I assume the client process wouldn't have more then one layer...

- otherwise we call WKMakeRenderLayer(renderContextID)
   - WKMakeRenderLayer presumably creates one side of a CALayer that  
is shared between the host and the client
   - This shared layer is added to the existing layer hierarchy in the  
browser and presumably drawn as though it was a regular layer

- Printing is done using either the softwareRenderer or shuttling a  
bitmap between the plugin and the host.

Overall this seems like a good way to solve the cross-process hardware  
acceleration problem. The shared CALayer is simple and flexible  
(though it's unclear how they deal with synchronization).  
Unfortunately, this method is implemented using private webkit symbols  
(WKInitializeRenderServer, WKMakeRenderLayer) so it is not easy for us  
to use unless Apple publicly exports the interface that these  
functions use. I think it would be worth while to put pressure on  
Apple to do so.

-Jeff