Enabling more efficient transparent windowless painting
Hanne E. Larsen
hela at opera.com
Tue Apr 13 00:26:17 PDT 2010
On Mon, 12 Apr 2010 22:36:08 +0300, John Abd-El-Malek <jam at chromium.org>
> 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>
>> > On Fri, Apr 9, 2010 at 12:21 PM, Brett Wilson <brettw at google.com>
>> >> 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
>> >> > 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
>> >> > 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
>> > an internal buffer, possibly in some other format, then it doesn't
>> > explicitly clear the buffer. It can just overwrite the old RGBA values
>> > its own values. This optimization is much harder to do if the browser
>> > responsible for clearing the buffer.
>> >> > We'll also want a similar "draw to GL"/"draw to D3D" API shortly.
>> >> > 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.
>> 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.
Opera does unfortunately not return an error, but we will follow you and
return NPERR_GENERIC_ERROR in future releases.
>> 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
>> + * windowless plugins, rather than compositing themselves on the
>> + * allows the browser to optimize drawing of such plugins and to
>> + * desynchronize plugin painting and page painting. When the plugin
>> + * 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
More information about the plugin-futures