NPP_DrawImage NPAPI proposal.

Antoine Labour piman at google.com
Thu Apr 8 16:26:17 PDT 2010


On Thu, Apr 8, 2010 at 3:38 PM, Oleg Romashin <romaxa at gmail.com> wrote:

>
>
>> 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 ?
>>
> Do you mean we need some NPPVar for it? like  NPPVpluginWindowlessLocalBool
> in https://wiki.mozilla.org/Plugins:NokiaMaemoImageSurface ?
>

Probably something similar to Xembed: the plugin checks browser support for
it (with a NPN_GetValue) and tells the browser to enable this for a
particular instance (with a NPN_SetValue).


>
> - 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 ?
>>
> I was thinking about it... but not sure what is the best way to do it...
> could it be some replacement for NPP_SetWindow or something like that?
>

Well, you can't break existing plugins. So it would need to happen with
either new calls (e.g. GetSupportedPixelFormats/SelectPixelFormat), or some
Get/SetValue.


>
>
>> - x,y,width,height: in which coordinates are they (page, window, plugin) ?
>>
> plugin area clip rect, also it is the same coordinates which are coming
> with default GraphicsExpose event for  X-windowless API
>

Which is very loosely defined today, except in terms of "what firefox's
implementation does" :) See ASCII art in
http://src.chromium.org/viewvc/chrome/trunk/src/webkit/glue/plugins/webplugin_delegate_impl_gtk.cc?revision=43718and
related "interesting" behaviours from existing plugins.
So please make sure that is very well defined in your spec.


>
>> - translateX, translateY, scaleX, scaleY: what do they mean ?
>>
>
> practically it is cairo_matrix, which allow us to get plugin area (0,0)
> relative to data buffer (0,0),
> scale values will give us plugin area size relative to size given in
> NPP_SetWindow.
>
> See: "Example of NPP_DrawImage usage with cairo" on proposal wiki page
>
>
> instead of these values we can also use NPRect, which is defining plugin
> area in data buffer, probably it would be more easy.
>

Well, this is I guess a new concept that doesn't exist today: today plugins
aren't responsible for any browser-induced scaling. What decides the "plugin
area size" if not the NPWindow ? When does it change ?


>
>
>
>> - 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 ?
>>
> It is (0, 0) of browser page paint event clip rectangle.
>
> drawWindow(DOMWindow, r(5, 5, 100, 100), ingoreScroll = TRUE) - in this
> case byte 0 - will be 5, 5, in page coordinates.
>
> - is alpha premultiplied or not ?
>>
>  premultiplied, as default CAIRO_FORMAT_ARGB32.
>

> - the usage sample suggests that the underlying pixels already exists in
>> data when this function gets called, and that the plugin is responsible
>>
> this is just example,
>  https://bugzilla.mozilla.org/attachment.cgi?id=437921 - here in IPC
> version I'm creating for transparent plugins ARGB32 surface always, and
> clear it before plugin paint.
>
>> 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.
>>
>
> with out of process plugins browser should give standalone ARGB32 surface,
> and plguin will paint it with alpha...
> then browser should swap buffers, and do composite-OVER already painted
> ARGB32 surface to final buffer. (in case if it is transparent plugin)
>
>
>>
>> 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
>>
>
> Pepper is big...
> Do we have some implementation? at least  rendering part of pepper API for
> mozilla?
>

I don't know the status of Pepper in Mozilla. For Chrome you can probably
start at
http://src.chromium.org/viewvc/chrome/trunk/src/chrome/renderer/webplugin_delegate_pepper.cc?revision=43123&view=markup

Antoine


>
>
>> there, rather than bringing a 3rd drawing model to the table.
>>
>> Antoine
>>
>>
>>
>>
>>>
>>> _______________________________________________
>>> 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/9b6e9b8d/attachment.html>


More information about the plugin-futures mailing list