Enabling more efficient transparent windowless painting

John Abd-El-Malek jam at chromium.org
Mon Apr 12 12:36:08 PDT 2010


On Mon, Apr 12, 2010 at 11:23 AM, Brett Wilson <brettw at google.com> wrote:

> On Thu, Apr 8, 2010 at 9:49 PM, Robert O'Callahan <robert at ocallahan.org>
> wrote:
> > On Fri, Apr 9, 2010 at 12:21 PM, Brett Wilson <brettw at google.com> wrote:
> >>
> >> On Thu, Apr 8, 2010 at 4:50 PM, Robert O'Callahan <robert at ocallahan.org
> >
> >> wrote:
> >> > That basically sounds good to me. We only need this on X and Windows
> >> > where
> >> > X/GDI can't be trusted to set alpha values correctly.
> >> >
> >> > Why do you require the browser to clear the surface? Wouldn't it be
> more
> >> > efficient for the plugin to clear it?
> >>
> >> In Chrome this surface is in shared memory, so it doesn't matter who
> >> clears it from a perf perspective. I just thought it was nice to
> >> define what the state of the buffer is before handing it to the
> >> plugin.
> >
> > If the plugin knows its content is opaque, or it has the rendered content
> in
> > an internal buffer, possibly in some other format, then it doesn't need
> to
> > explicitly clear the buffer. It can just overwrite the old RGBA values
> with
> > its own values. This optimization is much harder to do if the browser is
> > responsible for clearing the buffer.
> >
> >> > We'll also want a similar "draw to GL"/"draw to D3D" API shortly. I'm
> >> > not
> >> > sure if it's worth lumping that in here or not.
> >>
> >> GL sounds like it's more of a replacement of the current painting
> >> model, whereas my proposal is more of a mode on the current one. Does
> >> this sound right to you?
> >
> > Yes.
> >
> >> Conceivably, the bitmap produced by my proposal could be converted to
> >> a texture for accelerated painting, although the plugin itself could
> >>
> >> not be accelerated.
> >
> > Indeed.
>
> http://mxr.mozilla.org/firefox/source/modules/plugin/base/public/npapi.h
>
> I've been working on the Chrome side of this change. My main question
> is: is it sufficient to say the plugin can set this variable, and if
> the SetValue is not an error, we can be assumed to be in this mode? Or
> do we need another "supports" flag?
>

That seems reasonable.  Firefox, Safari, and Chrome return an error when
they get a NPN_SetValue with an unknown variable.  Not sure about Opera.

http://mxr.mozilla.org/mozilla-central/source/modules/plugin/base/src/nsNPAPIPlugin.cpp
<http://mxr.mozilla.org/mozilla-central/source/modules/plugin/base/src/nsNPAPIPlugin.cpp>
http://trac.webkit.org/browser/trunk/WebCore/plugins/PluginView.cpp
http://src.chromium.org/viewvc/chrome/trunk/src/webkit/glue/plugins/plugin_host.cc?view=markup&sortby=rev
<http://src.chromium.org/viewvc/chrome/trunk/src/webkit/glue/plugins/plugin_host.cc?view=markup&sortby=rev>


>
> This is my change to the public API so far, does anybody have any
> comment? I will need to specify the behavior of it more precisely, but
> I'm going to wait until I actually have a demo first.
>
> --- npapi.h     (revision 44251)
> +++ npapi.h     (working copy)
> @@ -386,8 +386,15 @@
>   NPPVpluginWantsAllNetworkStreams = 18,
>
>   /* Checks to see if the plug-in would like the browser to load the
> "src" attribute. */
> -  NPPVpluginCancelSrcStream = 20
> -
> +  NPPVpluginCancelSrcStream = 20,
> +
> +  /* Set to true when the plugin will provide an alpha channel for
> transparent
> +   * windowless plugins, rather than compositing themselves on the page.
> This
> +   * allows the browser to optimize drawing of such plugins and to
> +   * desynchronize plugin painting and page painting. When the plugin is
> not
> +   * in transparent windowless mode, this has no effect. */
> +  NPPVpluginTransparentAlphaBool = 21
> +
>  #ifdef XP_MACOSX
>   /* Used for negotiating drawing models */
>   , NPPVpluginDrawingModel = 1000,
> _______________________________________________
> 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/20100412/c83d874c/attachment.html>


More information about the plugin-futures mailing list