WPE Architecture
WPE is the official WebKit port for embedded platforms. WPE is uniquely designed for embedded systems in that it doesn’t depend on any user-interface toolkit such as the traditional Cocoa, GTK, etc toolkits.
Web page rendering
WPE is considered a hybrid port because it defers the final web page delivery for display to a rendering backend. A traditional port would provide a widget for a given toolkit, but WPE opted for a different and more flexible approach.
The common interface between WPEWebKit and its rendering backends is provided by
libwpe. On one side, once
WPEWebKit has a graphical representation of the final composited Web page ready
for rendering, it invokes a callback function on libwpe. On the other side,
the WPE application has to register a view backend on the WPE WebView. This view
backend is provided by the rendering backend. The view backend receives the Web
page representation from libwpe, usually as an EGLImage, and is in charge of
presenting it in the application, on-screen.
The decoupling between generating the WebPage representation on WebKit side and the actual rendering on the application side provides a very flexible design. For instance, WPE integrators can easily develop a new rendering backend for specific embedded platforms that might have a graphics driver with special API requirements.
WPE provides a rendering backend aiming to target the most common platforms and leverage the existing graphics stack available in the Freedesktop umbrella eco-system. WPEBackend-FDO is the reference implementation of the base rendering backend design. WPEBackend-FDO provides an API for WPE applications that aims to ease the handling of rendering either on-screen using EGL, or off-screen using SHM.
Input events handling
In a traditional WebKit port, the provided widget usually also handles input (keyboard, mouse, touch) events and is in charge of relaying them to the internal WebKit input-methods components.
As WPE doesn’t provide a widget, it relies on libwpe APIs to relay input
events from the WPE application to the internal WebKit input-methods components.
This design again adds flexibility to the overall WPE architecture, enabling
applications to support new input devices without having to go through a UI
toolkit first.
In the example of the Cog WPE browser, the application relies on Wayland protocols for user input to communicate events coming from the Wayland compositor to WPE.
If you’re using WPE WebKit, or are considering doing so, please take our brief user survey. Your input will help us make WPE WebKit better for you!