CEF / WebKitGTK / BlinkGTK — choosing between them

Author: BlinkGTK Project
Version: 1.2.0-build2

If you want to embed a web engine in a GTK4 application, there are broadly three
options. This document sets out how the three differ structurally.

One thing up front: there are no performance figures for the other engines
here. Comparing fairly means rendering the same content under the same
conditions, and we are not able to maintain that continuously. Listing estimates
felt less honest than listing nothing. BlinkGTK's own numbers appear only where
we measured them, together with the conditions.

The difference that matters most

Read it like this:

• You want Chrome's rendering → CEF or BlinkGTK (both are Blink)
• You want it to behave like a GTK widget → WebKitGTK or BlinkGTK
• You want both → BlinkGTK

BlinkGTK sits where it does by going after Chromium's rendering and GTK-native
handling at the same time. The price is narrowing to Linux/Wayland. If you
ship to several operating systems, CEF is the straighter path; if WebKit's
rendering is fine for you, so is WebKitGTK.

What embedding looks like

The same "put the web in a window" differs in weight.

BlinkGTK — a GTK widget, so you just put it in the window.

GtkWidget *view = blink_web_view_new();
gtk_window_set_child(GTK_WINDOW(window), view);
blink_web_view_load_uri(BLINK_WEB_VIEW(view), "https://example.com/");

WebKitGTK — nearly the same shape. Different function names and types.

GtkWidget *view = webkit_web_view_new();
gtk_window_set_child(GTK_WINDOW(window), view);
webkit_web_view_load_uri(WEBKIT_WEB_VIEW(view), "https://example.com/");

CEF — you supply handler classes and hand control to CEF's message loop. It
starts at a few dozen lines of C++, and windows are managed outside the GTK
widget hierarchy.

If you are porting, coming from WebKitGTK is close to mechanical. The mapping
table is in
Migrating from WebKitGTK.

Wayland and GObject Introspection

Dropping X11 is a deliberate trade. Today's major desktops default to Wayland,
so the practical cost is small, while keeping to a single path buys a lot. If
X11 is a requirement, BlinkGTK is not an option for you.

Because it supports GObject Introspection, Python looks like this:

import gi
gi.require_version('BlinkGTK', '0.1')
from gi.repository import BlinkGTK

view = BlinkGTK.WebView.new()
view.load_uri('https://example.com/')

How big it is

Carrying Chromium, it is not small. Measured on BlinkGTK
1.2.0-build2:

If you are considering embedded hardware, check these numbers first. Where
storage is tight, the WebKit family is the realistic choice. Being
Chromium-based, CEF lands in the same order of magnitude.

Memory is the same story: Chromium spreads its work over several processes, so
budget a few hundred MB per WebView.

We ship RPM (Fedora), DEB (Debian / Ubuntu) and a tarball. The tarball runs from
wherever you unpack it.

What the API can do

The major capabilities are all there. For BlinkGTK, the entry points are:

Debugging splits along engine lines. BlinkGTK and CEF both give you Chrome
DevTools. WebKitGTK gives you Web Inspector.

Japanese typesetting

This is an area BlinkGTK deliberately invests in.

Vertical writing, ruby, emphasis dots, tate-chu-yoko and line-breaking rules are
supported, and we aim to follow JLReq (Requirements for Japanese Text Layout).
Problems we find are proposed as fixes to Chromium itself, so the work reaches
other Blink-based engines too.

Where the quality of Japanese typesetting is part of the product — e-book
readers, for instance — this can be the deciding factor.

Choosing

It is not a question of which is best but of what you can give up. BlinkGTK
gives up size and operating-system reach, and takes Chromium's rendering with
GTK's ergonomics in exchange.

References

• CEF: https://bitbucket.org/chromiumembedded/cef
• WebKitGTK: https://webkitgtk.org/
• BlinkGTK: https://blinkgtk.org/
• Chromium: https://www.chromium.org/

History