NPP_DrawImage NPAPI proposal.

Brett Wilson brettw at google.com
Fri Apr 9 08:03:07 PDT 2010


On Fri, Apr 9, 2010 at 1:52 AM, Oleg Romashin <romaxa at gmail.com> wrote:
>
> On Thu, Apr 8, 2010 at 11:23 PM, Antoine Labour <piman at google.com> wrote:
>>
>> On Thu, Apr 8, 2010 at 12:27 PM, Oleg Romashin <romaxa at gmail.com> wrote:
>>>
>>> Hi,
>>>
>>> On https://wiki.mozilla.org/Plugins:NPP_DrawImageNPAPI
>>> I'm proposing new NPP_DrawImage  API,  which some sort of improved
>>> version for NPImageExpose
>>>
>>> Can we get it as part of official NPAPI ?
>>>
>>> Here is the bug with this API implementation, non-IPC + IPC parts:
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=554270
>>>
>>> Br, Oleg
>>
>> A few comments, that I think should be addressed before making this an
>> official component of the spec.
>> - how does a plugin opt-in to this new drawing model ?
>> - who decides the pixel format ? Is it negotiated (how?) between the
>> plugin and the browser, or is just the browser's choice and the plugin needs
>> to support everything the browser throws at it ?
>> - x,y,width,height: in which coordinates are they (page, window, plugin) ?
>> - translateX, translateY, scaleX, scaleY: what do they mean ?
>> - data: where does byte 0 point to ? (0,0) in the page coordinates ? (0,0)
>> in the window coordinates ? (0,0) in the plugin coordinates ? (0,0) in the
>> clip rect coordinates ?
>> - is alpha premultiplied or not ?
>> - the usage sample suggests that the underlying pixels already exists in
>> data when this function gets called, and that the plugin is responsible for
>> doing the compositing itself. While this is similar to the existing drawing
>> model, we found it to be a major performance bottleneck with out-of-process
>> plugins because it means the page painting and the plugin painting need to
>> be synchronized.
>> Another point: significant work has already been invested into the
>> platform independent NPAPI to redefine 2D drawing into something that works
>> better for untrusted and OOP plugins, and that work is supported by 2
>> browser vendors and 1 major plugin vendor
>> (see https://wiki.mozilla.org/Plugins:PlatformIndependentNPAPI#2D_Rendering
>> ), so I would suggest bringing your thoughts into the design there, rather
>> than bringing a 3rd drawing model to the table.
>
> I read quickly
> https://wiki.mozilla.org/Plugins:PlatformIndependentNPAPI#2D_Rendering, I
> have some questions:
> 1) Is there are any example of how to get extension object?
> 2) https://wiki.mozilla.org/Plugins:PlatformIndependentNPAPI#Example - where
> is the description of  "NPDeviceContext2DConfig" ? what is it about and how
> to use it.
> 3)  "void* region" - according to spec it is always 32bpp BGRA format data:
>     a) can we make data format negotiation between plugin and browser

Yes, one of our engineers is working on how to negotiate the 3D
format, which could also be used for the 2D format. This isn't ready
quite yet, though.

>     b) I think it does not make sense to render opaque plugin into surface
> with alpha calculation ( it should be done only for transparent plugins ) -
> performance

It's certainly possible as an optimization to allow formats without alpha.

>     c) for some devices with low memory speed and default 16bpp visual
> format it is better and faster to render plugin data with some 16bpp format
> (opaque)


> 4) device2d->flushContext(npp, &context, NULL, NULL); - I think it should be
> possible to provide clip region for flush context... because if plugin
> updating just small part (10x10) for context with size 1000x1000, then
> browser must composite whole context area... and that is a bit expensive.

They way you specify this is by modifying the "dirty" rect in the context.

Brett


More information about the plugin-futures mailing list