PPAPI Interface Support

pepper.js was developed using test-driven development. Features are only added when tests are available (either automatic or manual). This means that even if an interface is supported, there may be missing features or subtle incompatibilities where test coverage is not available. Lack of test coverage will be the main difficulty in getting pepper.js to v1.0.

If an unimplemented interface is requested, pepper.js will return a null pointer and log the request to the JavaScript console. If an unimplemented function is called, an exception with be thrown.

To find which interfaces have been implemented, run the following command in the root of the repo:

git grep "registerInterface(\""

To find unimplemented functions:

git grep "not implemented"

pepper.js The "Probe Interfaces" example should also help discover what interfaces are available on a particular platform.

If you need a particular interface or function for your application, do not hesitate to file a feature request on the bug tracker. Test cases and patches are welcome, if you're particularly interested in the feature.

Unsupported Interfaces

There are currently a few Pepper Interfaces not supported by pepper.js. For example, PPB_MessageLoop is not supported because it only makes sense when additional threads are created. There are also a number of interfaces that simply haven’t been implemented, yet:

• PPB_Gamepad
• PPB_MouseCursor
• PPB_TouchInputEvent
• Networking-related interfaces
  • PPB_HostResolver
  • PPB_NetAddress
  • PPB_NetworkProxy
  • PPB_TCPSocket
  • PPB_UDPSocket
  • PPB_WebSocket

Implementation Errata

The Graphics2D and Graphics3D interfaces will automatically swap buffers every frame, even if Flush or SwapBuffers is not called. This behavior should not be noticeable for most applications. Explicit swapping could be emulated by creating an offscreen buffer, but this would cost time and memory.

Graphics3D may not strictly honor PP_GRAPHICS3DATTRIB_* parameters but best effort will be made to do something reasonable. WebGL provides less control than PPAPI, and pepper.js is implemented on top of WebGL. For example, if a 24-bit depth buffer is requested there will be a depth buffer but WebGL only makes guarantees that depth buffers are at least 16 bits.

In NaCl, PPB_View specifies coordinates in terms of device independent pixels (the resolution of your screen, divided by a constant factor for high DPI displays). Most DOM elements work in terms of CSS pixels, however, which are affected by zooming in or out on a page and other forms of full-page scaling. In effect, NaCl sees the rectangle it occupies on the screen grow and shrink when the page is scaled. NaCl can transform from device independent pixels to CSS pixels by using the scaling factor returned from GetCSSScale. pepper.js always works in terms of CSS pixels because JavaScript does not appear to expose such a scaling factor. GetCSSScale will always return 1. In effect, pepper.js does not see the rectangle it occupies change when zooming in or out on a page.

Using BGRA image formats will result in a silent performance penalty. In general, web APIs tend to be strongly opinionated that premultiplied RGBA is the image format that should be used. Any other format must be manually converted into premultiplied RGBA.

The Audio API only supports one sample rate - whatever the underlying Web Audio API uses, which is whatever the OS defaults to, which tends to be either 44.1k or 48k. 48k appears to be a little more common. This means that an app expecting a particular sample rate may not be able to get it, and this can cause serious difficulties. In the future, resampling could be performed as a polyfill, but this would be slow.

URLLoader intentionally deviates from the native implementation's behavior when it is at odds with XMLHttpRequest. For example, pepper.js does not identify CORS failures as PP_ERROR_NOACCESS, instead it returns PP_ERROR_FAILED.

URLLoader does not stream - the data appears all at once. This is a consequence of doing an XHR with requestType set to arraybuffer, it does not appear to give partial results.

If multiple mouse buttons are held, pepper.js will list all of them as event modifiers. PPAPI will only list one button - the one with the lowest enum value. There is a known bug where pepper.js will not update the modifier state if a button is pressed or released outside of pepper.js's canvas.

Platform Errata

PPB_Graphics3D does not work on Internet Explorer 10 or before because WebGL is not supported. IE11 supports WebGL to some extent, but it still has a way to go before it is considered a conformant implementation of WebGL 1.0. It is missing features such as bufferSubData and accepting arrays of byte indices when drawing elements. If you want a 3D app to work on IE11, you must test it on IE11 and find workarounds for missing features. WebGL is supported on Safari, but it must be manually enabled: https://discussions.apple.com/thread/3300585.

PPB_MouseLock and PPB_Fullscreen are only supported in Chrome and Firefox. The behavior of these interfaces varies somewhat between the two browsers, however. Safari supports fullscreen, but does not support mouse lock.

PPB_Fullscreen is nominally supported by IE11, but you can only enter fullscreen mode while handling a PP_INPUTEVENT_TYPE_MOUSEUP event.

The file interfaces are currently supported only by Chrome. (Creation and last access time are not supported, even on Chrome.) A polyfill for Firefox and IE is included in pepper.js, but it has a few known bugs - such as not being able to resize existing files. Another issue is that the Closure compiler will rename fields in persistent data structures, resulting in data incompatibility/loss between Debug and Release versions, and possibly even between different Release versions.

Chrome will smoothly scale the image composited into the page when using pepper.js, all other browsers will do nearest-neighbor scaling. Native Client executables will do nearest-neighbor scaling in Chrome. This means low res or pixel style graphics will be slightly blurred on Chrome with pepper.js, unless the back buffer is the same size as the view port and the scaling factor for high DPI displays is accounted for.

Input events are a little fiddly due to inconsistencies between browsers. For example, the delta for scroll wheel events is scaled differently in different browsers. pepper.js attempts to normalize this, but in general, cross-platform inconsistencies should be expected in the input event interface.

The "readyState" attribute on a pepper.js pseudo-embed element cannot be emulated in IE. Reading "readyState" will always give "completed" for most DOM elements in IE, and this attribute cannot be overridden.

Mobile browsers have not been extensively tested.