Revised proposal for asynchronous drawing
josh at mozilla.com
Wed Mar 14 15:13:04 PDT 2012
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.
----- 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 , 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.
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.
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.
plugin-futures mailing list
plugin-futures at mozilla.org
More information about the plugin-futures