Pepper plugin implementation
Pepper plugin implementation
This document provides a quick reference for PPAPI integration in Chromium.
If you're adding a new API, see Pepper API Best Practices for helpful guidelines and our process is documented in Pepper API Proposals.
Quick reference to important code locations
Issue trackingWe're tracking PPAPI bugs in the Chromium issue tracker to keep things simpler. To file a pepper-related bug, use all of the following labels:
If the bug relates to a Native Client specific part, additionally use the label:
Running a plugin in ChromeThere are two modes of operation, "trusted" and "untrusted" plugins. Untrusted plugins use the Native Client to safely run code from the web and is cross-platform. Trusted plugins are loaded directly in either the renderer process or a separate plugin process as platform-specific libraries.
You run a plugin in trusted mode by building a platform-specific library implementing the API. For random manual testing, you can use one of the examples, the graphics 2D "paint manager" example is a good one for general hacking (see ppapi/examples/2d/). A trusted plugin is instantiated by registering it to handle a MIME type on the command line. Provide the full plugin name (which varies by platform), followed by a semicolon, followed by the MIME type. The MIME type should match the "type" attribute of the object tag specified on your page. For the paint manager example plugin on Linux, you would run:
In this case, application/x-ppapi-example-2d is what is specified in the example.html page. This can be anything you want, as long as the two types match. Note also that we specify --ppapi-out-of-process. In-process mode is being deprecated so it's a good idea to use this in general.
On Linux, you can automatically launch this process in a new GDB instance in a new xterm, which will help you in debugging startup problems. Use this command line switch:
"Old" resource and proxy designMost resources are currently implemented using the old proxy design. There are several layers, and each resource is implemented once for in-process and once for out-of-process.
The in-process implementations are in content/renderer/pepper/ppb_*_impl.* These integrate with the rest of Chrome by using blink or other parts of content/renderer.
The proxy implements interfaces for the out-of-process case. They are implemented in ppapi/proxy/ppb_*_proxy.* The proxy has a ppapi/proxy/dispatcher.h on each end of the IPC channel. The specialization PluginDispatcher is on the plugin side, and the specialization HostDispatcher is on the renderer side. Each interface has a Proxy object for which there is one per dispatcher, and a resource object that corresponds to the PP_Resource object.
Some proxy objects and implementations share some or all of their code. Shared code can be put into ppapi/shared_impl/ppb_*_shared.* to avoid duplication.
Life cycle of a plugin -> renderer call:
Unlike the "new" design there is no standard way of communicating with the browser. Some components (TCP/UDP sockets) do this with hand-rolled tracking.
"New" resource and proxy designAll additions should use the new proxy design. It is higher performance and involves writing much less code. The new and old designs exist in parallel and we're moving resources over one-by-one.
The resource object is implemented once (in ppapi/proxy/*_resource.cc). This resource sends IPC to a "host" object in the browser and/or renderer process to do its work. The host object does not speak the Pepper API, it just uses Chrome IPC types. It can be in the renderer process, the browser process, or potentially both or neither (if all functionality is contained in the plugin process). It can also be implemented in the chrome or the content modules.
Where does your host object live?
Each of the above directories has a "host factory" file in it for creating the hosts for your resource. You'll also have access to the BrowserPpapiHost / RendererPpapiHost which will allow you to make calls into the system and get context for your resource. We support in-process mode for legacy interfaces needed by certain plugins. New resources do not need to support in-process. For resources that need in-process, we have a "fake" IPC channel that allows the "proxy" and "host" to be in the same process. To wire this up, first get your out-of-process implementation working, then hook up creation through content/renderer/pepper/pepper_in_process_resource_creation.cc. Note that this only works for resources implemented in content/renderer. Other types of hosts are not supported in in-process mode.
Life cycle of a plugin -> renderer call
Note that creation is a separate step. The resource creates the host in the browser or renderer by calling SendCreateToBrowser or SendCreateToRenderer. This is picked up by the host factory in the directory holding the resource.
Adding a new interfacePlease look at our Pepper API Process Doc before starting to implement a new API.
To make the interface definitions (this is the same between the "new" and "old" proxy designs):
To hook up your interface (this is the same between the "new" and "old" proxy designs):
Implement the resource "proxy" (this is different from the "old" design):
Implement the resource "host" (this is different from the "old" design):
Designing your interfaceFeatures are implemented as "interfaces." An interface is just a vtable identified by a string name. Most features are implemented as "resources" which are generic refcounted project identified by an opaque handle. Your normally have an interface that exposes all the functions your resource supports.
Writing error logsIn a resource implementation, use Resource.Log() to display a message in the console (in the JS inspector) for the page. In other places, use PpapiGlobals::LogWithSource().
Architecture of the renderer implementationIt may help to open the NPAPI plugin architecture design doc in another tab. This section will compare Pepper to the "in process" NPAPI implementation. Most of the names are the same between Pepper and NPAPI, except we use the webkit::ppapi namespace and NPAPI uses the webkit::npapi namespace. If you haven't already, you should also understand the important concepts of PPAPI.
Debugging a pluginTrusted plugins are loaded directly into the renderer sub-process, rather than a separate plugin process. You can use the standard renderer debugging techniques, including single process mode, for debugging the plugin.
Plugins also run in the renderer sandbox. You will find your plugin code is constrained to the same requirements and limitations as other code in the renderer (can't read and write files or directly access devices).
Running the testsThe tests in ppapi/tests are run as part of the Chrome browser_tests. The source code is in chrome/test/ppapi and you can see in that file there are separate GTest tests for each PPAPI test file. To just run this test, you can use:
Or to run tests out of process:
You can also run the tests manually in Chrome. You first need to build the test plugin, which is the ppapi_tests project, and build Chrome (PPAPI doesn't work in test shell). When running Chrome, enable the PPAPI testing interface (it's off by default to prevent production plugins from abusing this API) and register the test plugin as handling the application/x-ppapi-tests MIME type:
The library name is platform-specific. On Linux, use libppapi_tests.so in the output directory. On Mac, use ppapi_tests.plugin. Once Chrome is running, just load the test_case.html file in the browser. Set the "query" part of the URL to be the name of the test you want to run, for example to run the ImageData tests, load:
You will see a log of the test cases in the gray square. If the plugin doesn't load, you will see an error message above the gray square indicating that the plugin could not be found. This means that the library name is incorrect or it failed to load for some reason.
Running HTTP tests manuallySome tests like the URLLoader test require that it be run over HTTP. The Chrome browser tests are configured to automatically do this. But for debugging purposes you may want to do this manually. From your src directory on Linux, do:
and on Windows, use:
Then you should be able to load http://127.0.0.1:1337/files/test_case.html in your browser. Running NaCl tests manuallyThe NaCl tests also must be run over HTTP, but they are loaded from the build output directory instead of ppapi/tests. So to start the test server for NaCl tests on Linux for a Debug build, do:
and on Windows, use:
The command-line for running NaCl tests is different; you don't need to load the test plugin, but you do need to enable NaCl:
You must append "&mode=nacl_glibc" or "&mode=nacl_newlib" to the URL. E.g.: load http://127.0.0.1:1337/files/test_case.html?testcase=URLLoader&mode=nacl_glibc in your browser.
Testing with FlashRunning a local build with Flash is slightly different. You can usually run a local build of Chromium with a Flash plugin that comes with a recent Chrome distribution (for example, Canary or Dev Channel) using --ppapi-flash-path and --ppapi-flash-version (gotten from the "Manifest.json" file that is bundled alongside the Flash plugin in Chrome. For example, on Linux you could type:
Instead of specifying the matching flash version you can specify 99.99.99.99, like this: --ppapi-flash-version=99.99.99.99. This gives a possible command line for Windows of this:
There are no specific gn args needed to run flash in a local build - non-official, component, and debug/release builds all work fine.
Make sure that the bitness (32-bit versus 64-bit) of your local build matches that of the DLL that you specify.
|
Pepper plugin implementation的更多相关文章
- Advanced Plugin Concepts
Provide Public Access to Default Plugin Settings An improvement we can, and should, make to the code ...
- GPU Command Buffer
For Developers > Design Documents > GPU Command Buffer This are mostly just notes on the ...
- 居然是Firefox没有抛弃我们
面向企业级市场,一款网页浏览器的很多特性不是说改就改,说丢弃就丢弃.就像微软不能抛弃IE一样,Firefox也有类似的定位和使命. Firefox即尝试提供企业级市场所需的特性稳定的软件版本(LTS) ...
- jQuery插件开发(转)
jQuery插件开发全解析 jQuery插件的开发包括两种: 一种是类级别的插件开发,即给jQuery添加新的全局函数,相当于给jQuery类本身添加方法.jQuery的全局函数就是属于jQuery命 ...
- jQuery命名空间,插件开发
jQuery插件的开发包括两种: 一种是类级别的插件开发,即给jQuery添加新的全局函数,相当于给jQuery类本身添加方法.jQuery的全局函数就是属于jQuery命名空间的函数,另一种是对象级 ...
- jQuery插件的开发之$.extend(),与$.fn.extend()
jQuery插件的开发包括两种: 一种是类级别的插件开发,即给jQuery添加新的全局函数,相当于给jQuery类本身添加方法.jQuery的全局函数就是属于jQuery命名空间的函数,另一种 ...
- 面试题HTML +CSS
HTML+CSS部分1.行内元素和块级元素?img算什么?行内元素怎么转化为块级元素?行内元素:和有他元素都在一行上,高度.行高及外边距和内边距都不可改变,文字图片的宽度不可改变,只能容纳文本或者其他 ...
- [Js/Jquery]立即执行匿名函数
摘要 有时使用js写了一个匿名方法,需要立即执行.因为没有方法名称,无法在其它地方调用. 匿名函数 匿名函数,可以认为是没有方法名称的函数. js中如果想执行匿名函数,结构如下: (function ...
- 基于Jquery、JqueryUI插件编写
刚开始编写jquery插件的时候,只是从网上找个模板看着写,并不理解.刚刚仔细把官网的API看了下,突然觉得豁然开朗了.马上放假了想着应该整理整理不然忘了又. How to create a Jque ...
随机推荐
- 高斯滤波及高斯卷积核C++实现
高斯滤波是一种线性平滑滤波,适用于消除高斯噪声,在图像处理的降噪.平滑中应用较多,特别是对抑制或消除服从正态分布的噪声非常有效. 高斯滤波的过程其实就是对整幅图像进行加权平均操作的过程.滤波后图像上每 ...
- Linux就该这么学 20181004(第六章磁盘管理)
参考链接https://www.linuxprobe.com/ /boot 开机锁需要文件-内核.开机菜单以及所需配置文件 /dev 以文件形式存放的任何设备与接口 /etc 配置文件 /home 用 ...
- JavaScript学习记录三
title: JavaScript学习记录三 toc: true date: 2018-09-14 23:51:22 --<JavaScript高级程序设计(第2版)>学习笔记 要多查阅M ...
- C#调用GPG命令进行加密解密文件操作
public void GPG() { string password = "1234567890"; System.Diagnostics.ProcessStartInfo ps ...
- Codeforces 959E. Mahmoud and Ehab and the xor-MST 思路:找规律题,时间复杂度O(log(n))
题目: 解题思路 这题就是0,1,2...n-1总共n个数字形成的最小生成树. 我们可以发现,一个数字k与比它小的数字形成的异或值,一定可以取到k与所有正整数形成的异或值的最小值. 要计算n个数字的情 ...
- 1806最大数 string和sort函数用法
1.C++自带sort函数用法 sort函数有三个参数: (1)第一个是要排序的数组的起始地址 (2)第二个是结束的地址(最后一位要排序的地址) (3)第三个参数是排序的方法,可以是从大到小也可是从小 ...
- javascipt入门
一.javascript简介 javascript:(基于对象的编程语言:内部很多对象,我们只需要使用即可,几乎不需要自己创建对象) ECMAScript DOM BOM 存放位置: 建议代码放到ht ...
- pthread_cleanup_push vs Autorelease VS 异常处理
黑幕背后的Autorelease http://www.cnblogs.com/feng9exe/p/7239552.html objc_autoreleasePoolPush的返回值正是这个哨兵对象 ...
- Docker学习笔记(1)----认识Docker
1. 什么Docker? Docker是一个能把开发的应用程序自动部署到容器的引擎,它使用go语言编写的开源引擎,它在github上面个的地址为:https://github.com/docker/d ...
- 计算 List 数据的属性值的总和
List<PostRushPretreatmentMember> taskMember = pre.getTaskMember();///成员分配情况 Integer taskOrderN ...