Download - Wayland support in WebKit2GTK+ (GUADEC 2014)
Wayland support in WebKitGTK+Žan DoberšekIgalia
Strasbourg, July 28th, 2014
I - Overview of WebKit
3/27
WebKit - a portable Web engine
In memoriam: Chromium, Qt
PCs, phones, TVs, IVI, smartwatchesMac, iOS, 2 flavors of the Windows port, EFL, GTK
··
4/27
About the fork
via WebKit Memes
5/27
WebKitGTK+, the GTK+ port
... but really a GNOME port.
Web, Evolution, Yelp, Liferea ...
Highlights of the past year:
WebKit1 removedMultiple WebProcessesThe NetworkProcessCMake replaced Autotools
····
6/27
WebKitGTK+, the GNOME port
Future work
Stability and securityPerformanceWebRTC, WebCrypto and other W3C/WHATWG standardsMore processes! (storage, workers)Wayland support
·····
7/27
II - Overview of Wayland
8/27
Wayland
The successor to the X windowing systemPCs, phones, TVs, IVI
··
9/27
Wayland support in GNOME
Ever improving!
10/27
III - Wayland support in WebKitGTK+
11/27
General overview
Basic support relies on GTK+Accelerated Compositing requires an inventive approachThe problem with the Netscape plugins
···
12/27
Accelerated Compositing
Triggered by specific content - HTML video, HTML canvas, WebGL, CSStransforms, CSS filters ...Also enforcable (no need for triggers)Hardware-accelerated compositing of rendered layers throughOpenGL/OpenGLES
·
··
13/27
The obligatory WebKit2 diagram
via WebKit Trac
14/27
Implementation under X
Relies on XcompositeUIProcess prepares an X windowThe window handle is passed to the WebProcessThe WebProcess creates a GL context for that handle
····
15/27
Implementation under Wayland
Implemented using a nested Wayland compositor in the UIProcessWebProcess essentially an EGL client of that compositor
··
16/27
Implementation under Wayland
A small extension to the Wayland protocol is required.
Necessary to map the compositor client to the correspondingWebKitWebViewAppropriate for 1:1 and 1:N UIProcess-to-WebProcess mappings
·
·
17/27
Necessary bits
Basic Wayland support by your driver.
Hopefully you're using Intel.
Some additional EGL extensions are required.
GL_OES_EGL_image_externalEGL_KHR_image_baseEGL_WL_bind_wayland_display
···
18/27
Testing under Wayland
WebKit has a large suite of layout tests (> 30,000).
Many of these compare pixel output to a specified baseline or a reftest.
Performance tests should measure performance - correctness ensured bythe layout tests.
Hardware rasterizer can produce varying results over different runsRunning the tests will probably require the software rasterizer
··
19/27
Future work
The target is WebKitGTK+ 2.6.
Bug polishImprovements in performanceWebGL supportPossible subsurface-based implementationNetscape plugins?
·····
20/27
III.I - Demos
21/27
IV - Putting it all on Raspberry Pi
22/27
Because why not?
Everyone's favourite mini-computer.
Only prototyping for now.
23/27
State of the drivers
Current drivers are only partially openWayland support is presentMesa drivers are on their way
···
24/27
Alas, problems
The GtkWidget's Cairo surface draws into a shared memory buffer.
This buffer is attached to the wl_surface.
Constant redraws become inefficient.
The subsurface-based nested compositor allows to avoid queueingconstant redraws on the GtkWidget.
25/27
Alas, more problems
Hardware.
Solution - treat it as a challenge.
Support for JavaScriptCore on non-iOS ARM targets.
Single-core 700MHz ARMv6 CPU512MB RAM(No complaints with the GPU)
···
26/27
V - QuestionsThank you.
27/27