Revised proposal for asynchronous drawing

Bill Appleton billappleton at dreamfactory.com
Thu Mar 15 08:08:11 PDT 2012


I wish the Windows interface ran more like the Mac. The Mac seems to have a
clever way of isolating the plugin in a process. Windowed mode on Windows
has become less useful due to z-order issues anyway.

Are you going for accelerated drawing or real 3D? Seems like real 3D would
require OpenGL for portability, but accelerated buffering or page flipping
could be abstracted and use any method. The DirectX surface is analogous to
the Macs CGContext way of drawing.

Most of the security issues are due to NPAPI trying to interact with the
browser and be part of the web page, especially if the end user doesn't
know the plugin is on the page. One way forward is to focus on MIME types
as a way to launch applications from browser pages. This is announced to
the user and compatible on tablets and phones. Just a thought.

Bill



On Wed, Mar 14, 2012 at 6:24 PM, Adam Barth <abarth-mozilla at adambarth.com>wrote:

> To phrase this a different way, do you expect other browser vendors to
> implement this API?  It seems unlikely that Safari will implement it
> since it involves DirectX, which doesn't exist on OS X.  From Darin's
> message, it seems unlikely that Chrome will implement it either.
>
> Adam
>
>
> On Wed, Mar 14, 2012 at 6:02 PM, Adam Barth
> <abarth-mozilla at adambarth.com> wrote:
> > Why choose DirectX over OpenGL?  I'm surprised to see Mozilla
> > advocating for a Microsoft-proprietary API over an open standard like
> > OpenGL.
> >
> > Adam
> >
> >
> > On Wed, Mar 14, 2012 at 3:13 PM, Josh Aas <josh at mozilla.com> wrote:
> >> NPAPI isn't a sandbox-able API in general, and it's unlikely that it
> will become one. It's only possible to sandbox an NPAPI plugin if you have
> detailed knowledge of a specific plugin's behavior. We recognize this fault
> inherent to NPAPI and because of it we recommend that people avoid using
> NPAPI plugins. We're committed to presenting alternative solutions as
> quickly as possible via open web standards.
> >>
> >> While we work on transitioning plugin-based applications to open web
> standards we're interested in incremental improvements to NPAPI like this
> one. It can be delivered quickly and at low cost, with significant benefits
> for our users.
> >>
> >> As for portability, this API includes a portable bitmap drawing model.
> Note that this bitmap model is sandbox-able. We included a Windows-specific
> accelerated async API because the reality is that market share makes it
> worthwhile. It is also a more flexible model, including capabilities that
> vendors have requested. I'll let another Mozilla developer (Bas) comment on
> that.
> >>
> >> As we've stated before re: Pepper, we're not interested in designing
> and implementing an entire new binary platform API for plugins, one that
> will ultimately duplicate the capabilities of open web standards. We remain
> interested in incremental improvements that can be delivered quickly during
> the transition away from NPAPI.
> >>
> >> -Josh
> >>
> >> ----- Original Message -----
> >> From: "Darin Fisher" <darin at chromium.org>
> >> To: "Josh Aas" <josh at mozilla.com>
> >> Cc: "plugin-futures" <plugin-futures at mozilla.org>
> >> Sent: Wednesday, March 14, 2012 2:23:00 PM
> >> Subject: Re: Revised proposal for asynchronous drawing
> >>
> >> From the Chrome team, we have concerns about this API. Primarily, we
> are concerned that it will not be possible to sandbox the DirectX usage.
> While it obviously true that ordinary windowed plugins cannot be sandboxed
> either, due to their usage of HWNDs, we would prefer to see improvements
> that enable sandboxing.
> >>
> >>
> >> Given how much NPAPI plugins are a target of hackers [1], it seems wise
> to pursue a plugin model that can be sandboxed.
> >>
> >>
> >> I think we are also concerned about portability as there are no
> provisions for accelerated rendering on other platforms.
> >>
> >>
> >> In contrast our approach with Pepper has been to expose an Open GL ES
> 2.0 interface that ties into the browser's existing WebGL backend. It
> provides portability (via ANGLE) and an opportunity to aggressively sandbox
> the plugin.
> >>
> >>
> >>
> >> Regards,
> >> -Darin
> >>
> >>
> >> [1]
> http://www.zdnet.com/blog/security/how-google-set-a-trap-for-pwn2own-exploit-team/10641
> >>
> >>
> >>
> >> On Fri, Mar 2, 2012 at 7:42 AM, Josh Aas < josh at mozilla.com > wrote:
> >>
> >>
> >> Mozilla has updated the async drawing models proposal. We've landed an
> async bitmap drawing model implementation in our nightly Firefox builds,
> which we built in order to test the API design. This is pref'd off by
> default, pending approval of the specification.
> >>
> >> http://wiki.mozilla.org/NPAPI:AsyncDrawing
> >>
> >> Questions? Comments?
> >>
> >> Note: The last mail about this API was in November 2011. It discusses
> some blocking and paint throttling issues that we've worked to
> resolve/mitigate.
> >>
> >>
> https://mail.mozilla.org/pipermail/plugin-futures/2011-November/000493.html
> >>
> >> --
> >> Josh Aas
> >> Mozilla Corporation
> >>
> >> _______________________________________________
> >> plugin-futures mailing list
> >> plugin-futures at mozilla.org
> >> https://mail.mozilla.org/listinfo/plugin-futures
> >>
> >> _______________________________________________
> >> plugin-futures mailing list
> >> plugin-futures at mozilla.org
> >> https://mail.mozilla.org/listinfo/plugin-futures
> _______________________________________________
> 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/20120315/8ac73eba/attachment-0001.html>


More information about the plugin-futures mailing list