Update: NPAPI Plugins on Mac OS X

I’ve been spending a good amount of time this week planning changes to our NPAPI plugin architecture on Mac OS X. I have filed bugs and set up a wiki page to document this planning.

This first section of the wiki page describes improvements I hope to make to our plugin code for Gecko 1.9. Supporting NP_GetEntryPoints should make things easier for plugin authors and keep us in sync with WebKit. Using a slower idleEvent timer for plugins that are not in a foreground tab on the key window should help with CPU usage when people have lots of plugins in different tabs. Supporting Mac OS X NPAPI Drawing Models means we can support 64-bit plugins and allow 32-bit plugins to draw using CoreGraphics.

The second section points readers to the current revision of the Mac OS X NPAPI Drawing Models spec. It is not final, there will most likely be quite a few revisions and additions (in particular, an OpenGL Drawing Model). I have already started implementing some of it just to see how it goes, but I won’t be posting anything until the spec is final of course. This spec was originally created to solve the problem of 64-bit plugins on Mac OS X, but it actually also solves the more immediate problem of 32-bit plugins being able to use CoreGraphics and thus it has the general title of Mac OS X NPAPI Drawing Models. A separate proposal might eventually come out to modernize event handling data types, but that isn’t on the table yet.

7 thoughts on “Update: NPAPI Plugins on Mac OS X

  1. >Supporting 64-bit Mac OS X NPAPI means we’ll be
    >ready when 64-bit versions of Mac OS X come out and

    I thought that Panther on the G5 was running in 64 bit mode and that Apple was shipping “Fat” binaries with both 32 and 64 bits bundles into it…..

  2. Looks really interesting. One note: in the end of the proposal on the wiki, anyone is encouraged to comment on the plugin-futures list, but I can’t find out how to subscribe to it. Is it not public?

  3. Also, will the new drawing model spec make it possible for us to direct plugin drawing to an offscreen pixel buffer, so we can, for example, rotate it when the plugin is inside an SVG transform? Mac really needs a windowless plugin model…

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s