NPP_DrawImage NPAPI proposal.

Brett Wilson brettw at google.com
Thu Apr 8 16:15:54 PDT 2010


On Thu, Apr 8, 2010 at 3:50 PM, Oleg Romashin <romaxa at gmail.com> wrote:
>
>
> On Fri, Apr 9, 2010 at 12:48 AM, Brett Wilson <brettw 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
>>
>> Sorry, I'm pretty unclear on what this is for and what problem it is
>> trying to solve, especially since the description seems specific to X
>> windows. Can you further clarify this? Would it be useful to Windows?
>
> I think for windows it is not a problem at all, not sure but I think there
> are no such problem on windows as moving data from server-client-server....
>
>
>>
>> The problem that I imagine and hope you're trying to solve is the
>> transparent windowless painting problem where the plugin requires the
>> background of the page to paint over. When you run plugins
>> out-of-process like Chrome and Mozilla, the background of the page has
>> to be sent to the plugin, the plugin draws on it, and then the whole
>> thing gets sent back.
>
> This also possible with default X-windowless API, but problem are appearing
> when you trying to create 32bpp surface from non-default visual.... (for me
> gdk_image_new just crashes when I'm trying to create image with 32bpp
> visual)
>
> We have fixed that problem in maemo X-plugin.... but some other plugins
> still expecting page background data to be painted...
>
> Most important target for this API, is to avoid of moving data between
> X-Server and Client, and allow plugins paint directly to client.
>
>>
>> If this is the problem you're trying to solve, why not create a new
>> mode where the plugin is required to emit an alpha channel in the
>
> I was trying to understand what is NPAPI definition about transparent
> plugins rendering... and correct alpha support...
> But I think we need separate mode flag for checking that plugin is
> supporting proper work with alpha....., I will propose it in another wiki
> page.
>
>>
>> normal painting flow so the browser can composite the way it wants?
>> Why do we need these new functions and structures?
>
> This proposal mostly for linux, and unix with X-Server....

I think I see the problem you are trying to solve. This does not
affect Chrome because of Chrome's different rendering model, and we
would not implement it. I will leave it to the people who it may
affect to decide whether this addition is worthwhile.

I have an incremental proposal to fix the transparent windowless
problem I will post in a new thread (I was working on this yesterday).

Brett


More information about the plugin-futures mailing list