NPP_DrawImage NPAPI proposal.

Oleg Romashin romaxa at gmail.com
Thu Apr 8 16:34:53 PDT 2010


On Fri, Apr 9, 2010 at 2:26 AM, Antoine Labour <piman at google.com> wrote:

>
>
> 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 ?
>

For desktop firefox  plugin window size changed on layout reflow,zoom
For fennec/microb it changes only on reflow,  zoom is just scaling graphics
context (canvas->scale)

Here is the patch for fennec which is also changing plugin window size when
page is zoomed (flash does good fonts scaling)
https://bugzilla.mozilla.org/show_bug.cgi?id=553943



>
>>
>>
>>
>>> - 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/20100409/4532becd/attachment-0001.html>


More information about the plugin-futures mailing list