NPP_DrawImage NPAPI proposal.

Oleg Romashin romaxa at
Fri Apr 9 01:52:41 PDT 2010

On Thu, Apr 8, 2010 at 11:23 PM, Antoine Labour <piman at> wrote:

> On Thu, Apr 8, 2010 at 12:27 PM, Oleg Romashin <romaxa at> wrote:
>> Hi,
>> On
>> 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:
>> 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
> ),
> so I would suggest bringing your thoughts into the design there, rather than
> bringing a 3rd drawing model to the table.

I read quickly, I
have some questions:
1) Is there are any example of how to get extension object?
2) - 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
    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 ) -
    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

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.

> Antoine
>> _______________________________________________
>> plugin-futures mailing list
>> plugin-futures at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the plugin-futures mailing list