89
edits
NPAPI:Pepper: Difference between revisions
Jump to navigation
Jump to search
→Plugins and rendering
| Line 83: | Line 83: | ||
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. | ||
== Plugins and | == Plugins and Rendering == | ||
We propose generalizing the concept of rendering to include 2D RGBA, 3D, audio, and possibly other approaches. To facilitate this, we propose the addition of a new struct type. | |||
=== 2D Rendering === | |||
Currently plugins typically display 2D graphics in one of two modes: windowless or windowed. In the current state of affairs windowless plugins are typically given an RGB surface containing the contents of lower layers and they composite themselves. This constrains the use of transparency and complicates plugins that are not the top or bottom layer. Furthermore, basically all access to 3D accelerated graphics are through the latter. Windowed plugins provide a number of challenges to plugin and browser writers. First, windowed plugins are essentially given a handle to an operating system native window, from which all interaction by the plugin is completely platform-specific. Second, native windows make it very difficult for the browser to do CSS overlays, etc. Third, although NPAPI provides the NPP_HandleEvent API, this is not well-defined with respect to native windowing system events. | Currently plugins typically display 2D graphics in one of two modes: windowless or windowed. In the current state of affairs windowless plugins are typically given an RGB surface containing the contents of lower layers and they composite themselves. This constrains the use of transparency and complicates plugins that are not the top or bottom layer. Furthermore, basically all access to 3D accelerated graphics are through the latter. Windowed plugins provide a number of challenges to plugin and browser writers. First, windowed plugins are essentially given a handle to an operating system native window, from which all interaction by the plugin is completely platform-specific. Second, native windows make it very difficult for the browser to do CSS overlays, etc. Third, although NPAPI provides the NPP_HandleEvent API, this is not well-defined with respect to native windowing system events. | ||