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

Adding back dev-platform cc as it seems like a better list then dev- 
tech-dom.

On 15-Jun-09, at 3:17 PM, Chris Jones wrote:

> Jeff Muizelaar wrote:
>> 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.
>> Shouldn't windowless plugins be easier to support then windowed  
>> ones? Is there any reason you can't just create a surface in a  
>> region of memory shared between the plugin process and the Gecko  
>> process? It's not clear to me what problems are solved by using  
>> Xdamage and Xcomposite.
>
> It's just disgustingly easy to ship XID's from the content to plugin  
> process.  Also, all of the Xdamage/Xcomposite code is written and  
> tested.  Again, this is the short-term (i.e. something shippable as  
> soon as possible) and not long-term (i.e. something we're entirely  
> happy with) plan.

If the Xdamage/Xcomposite code you're talking about is the Fennec/ 
Hildon code, you won't be able to use that code out of the box because  
it's designed for making all windowed plugins act like windowless  
plugins and does scary and limited event forwarding. I've also only  
ever tested it with flash and a test plugin.

Currently we have code paths for:
- Windowed plugins
- Windowless plugins
and an optional one (#ifdef'd to replace the windowed plugins path) for:
- Windowed plugins that act like windowless plugins
with this approach we'd add a another path for:
- Windowless plugins that act like windowed plugins that act like  
windowless plugins
and that scares me a little bit.

My guess is that modifying Xdamage/Xcomposite code to fit your needs  
won't be any easier then just using a shared memory surface. Further,  
if we're not going to use that approach in the end it seems better to  
just do it right the first time. However, if you've already got  
windowless plugins working using Xdamage/Xcomposite, I guess we can  
always move to a saner approach later on.

-Jeff