Revised proposal for asynchronous drawing
darin at chromium.org
Wed Mar 14 11:23:00 PDT 2012
>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
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.
> 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.
> Josh Aas
> Mozilla Corporation
> plugin-futures mailing list
> plugin-futures at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the plugin-futures