Enabling more efficient transparent windowless painting

Brett Wilson brettw at google.com
Thu Apr 8 16:23:06 PDT 2010

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

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

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).


More information about the plugin-futures mailing list