Enabling more efficient transparent windowless painting

Antoine Labour piman at google.com
Thu Apr 8 16:32:29 PDT 2010

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


> Brett
> _______________________________________________
> plugin-futures mailing list
> plugin-futures at mozilla.org
> https://mail.mozilla.org/listinfo/plugin-futures
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/plugin-futures/attachments/20100408/0f7afd79/attachment.html>

More information about the plugin-futures mailing list