NPP_DrawImage NPAPI proposal.
romaxa at gmail.com
Thu Apr 8 15:38:44 PDT 2010
> 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 ?
- 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?
> - 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
> - 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
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.
> - 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
> there, rather than bringing a 3rd drawing model to the table.
>> plugin-futures mailing list
>> plugin-futures at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the plugin-futures