89
edits
NPAPI:Pepper: Difference between revisions
Jump to navigation
Jump to search
→Plugins and Rendering
| Line 94: | Line 94: | ||
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. | 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 = | = Plugins and Rendering = | ||