NPP_DrawImage NPAPI proposal.

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


On Fri, Apr 9, 2010 at 2:15 AM, Brett Wilson <brettw at google.com> wrote:

> 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).
>
That would be nice..
because I have to deal we this case in bug:
 https://bug464966.bugzilla.mozilla.org/attachment.cgi?id=437596

+    int depth = (flags & DRAW_IS_OPAQUE) ? QX11Info().depth() : 32;
+    Visual *visual = GetVisualByDepth(QX11Info().display(), depth);
And do it only if plugin definitely supporting this...

Also plugins on maemo is supporting this.


> Brett
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/plugin-futures/attachments/20100409/77e568b4/attachment-0001.html>


More information about the plugin-futures mailing list