Revised proposal for asynchronous drawing

Maciej Stachowiak mjs at apple.com
Thu Mar 15 12:56:11 PDT 2012


I asked other folks at Apple what they think of this proposal.

- We believe the portable bitmap surface is not useful on Mac; the CoreAnimation drawing model is superior and is already used by nearly every popular plugin. Therefore we believe it would be a waste of time to implement this proposal on Mac and we do not plan to do so. We do not believe there is any advantage to offering this feature on Mac at all in any browser.

- No comment at this time on the Windows-specific modes.

- Maybe the portable bitmap mode is useful on Linux or older Windows versions.

Cheers,
Maciej

On Mar 14, 2012, at 6:24 PM, Adam Barth 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



More information about the plugin-futures mailing list