89
edits
Changes
→Plugins and Rendering
We observe that implementing NPN_PluginThreadAsyncCall this way results in additional call/callback/call latency for NPN_* calls. We believe this is reasonable to provide a well-defined interaction, but realize we may need to address the efficiency of this mechanism.
= Plugin Startup and Service Discovery =
The current process of starting a plugin involves some differences on various platforms. In Pepper, the plugin must export
<pre>
NPError API_CALL NP_Initialize(NPNetscapeFuncs* pNFuncs,
NPPluginFuncs* pPFuncs);
</pre>
and
<pre>
NPError NP_Shutdown(void);
</pre>
There is no requirement for NP_GetEntryPoints.
Browsers currently determine which plugins provide support for which mime types by various mechanisms. A common trait of these mechanisms is the idea that the browser must load each plugin in succession to invoke an API to determine the types it provides. A single method not involving loading all the plugins is desired, but remains to be done.
= Plugins and Rendering =
