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