Enabling more efficient transparent windowless painting

Brett Wilson brettw at google.com
Thu Apr 8 16:34:35 PDT 2010


On Thu, Apr 8, 2010 at 4:32 PM, Antoine Labour <piman at google.com> wrote:
> On Thu, Apr 8, 2010 at 4:23 PM, Brett Wilson <brettw at google.com> wrote:
>> Browsers implementing out of process plugins using transparent
>> windowless mode have a problem because the page background must be
>> sent to the plugin for painting. The result is some extra copies, and
>> forcing the plugin to paint every time the page changes. It would be
>> nice if the plugins could specify an image with an alpha channel that
>> the browser can cache and composite when required.
>>
>>
>> I've been looking to implement something in Chrome that helps this
>> problem that could be implemented quickly by both browser and plugin
>> vendors with little extra work. My thinking was it would work as
>> follows:
>>
>> 1. There would be a new NPNV that the plugin would use to enable this
>> mode in the browser. Older browser that don't support this will (I
>> hope) return an error when setting this mode, so the plugin will know
>> to fall back to the old way. This would enable transparent painting
>> mode.
>>
>> 2. In transparent painting mode, rather than supplying a reference to
>> a drawing surface with the background of the page already painted in
>> it, the browser would supply a premultiplied RGBA surface initialized
>> to all 0's to the plugin for paint events. This basically uses the
>> current codepath except avoids the copy of the page background, so
>> this is an easy change (at least in Chrome).
>>
>> 3. When receiving a paint event in this mode, the plugin will render
>> an RGBA image to the bitmap and not expect that the page background is
>> already there. The only change required from the plugin perspective is
>> that they need to emit an alpha channel and not do the compositing
>> themselves. I think this is an easy change for many popular plugins.
>>
>> 4. Chrome (and I assume other browses with out-of-process plugins)
>> maintain the plugin image in the browser to help desynchronize
>> painting. In this mode, when a plugin paint returns, it is copied to
>> this backing store like normal, and no change is required. Except now
>> it has an alpha channel. Now it can be painted to the page independent
>> of the page background, and painting the page will no longer require
>> asking the plugin to paint.
>>
>> 5. The only other change is a change to NPN_Invalidate in the browser.
>> Currently, browsers implement this by invalidating the given square of
>> the page, and the subsequent paint will paint the page background,
>> then the plugin. In this mode, NPN_Invalidate will immediately trigger
>> a paint message to the plugin to update its rendering of that
>> subsection of the plugin image. The return of this paint call will
>> then trigger an invalidate of the page (which no longer requires
>> plugin involvement and everything will be up-to-date).
>
> Question here: should the event be sent to the plugin before NPN_Invalidate
> returns (i.e. re-entering the plugin), or immediately after (i.e. after the
> plugin returns control to the browser, next message loop, ...) ?

I think it should not be re-entrant. The goal here is to make as few
changes to the browsers and the plugins as possible. Plugins now
expect to not be re-entered in NPN_Invalidate. Also, Chrome's
implementation of NPN_Invalidate will actually be in another process,
so it will naturally be non-reentrant from the plugin's perspective.

Brett


More information about the plugin-futures mailing list