89
edits
| Line 104: | Line 104: | ||
=== 2D Rendering === | === 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 | 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 windowed plugins. 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. | ||
To these ends we propose, for both 2D and 3D: | To these ends we propose, for both 2D and 3D: | ||
* Only windowless plugins should be supported. | * Only windowless plugins should be supported. | ||
* Compositing should be done | * Compositing should be done outside the plugin itself, which should only produce an RGBA (2D) or a texture (3D). | ||
* No native windowing system events should be delivered to plugins. | * No native windowing system events should be delivered to plugins. | ||
edits