wiki:WebKit/Overview

Version 4 (modified by nephele, 3 weeks ago) ( diff )

Add stuff from zardshards blog

This page gives an overview of the [WebKit port](​https://github.com/haiku/webkit), how it's done, where the useful sources are, etc.

There are two "versions" of WebKit called WebKiLegacy and "WebKit" or WebKit2. The former is a single-process architecture, where the whole browser is a single application. The latter is a multi-process system, where the browser is just a shell, and there are WebProcess (html parsing, etc) and NetworkProcess (http requests) programs running in the background to do the actual work, providing some sandboxing. Haiku is currently using the former, work is ongoing (in the webkit2 branch) for moving to WebKit2.

Build Instructions

See the README in the repo for details (especially if you're using a gcc2 system), but the short version is:

Tools/Scripts/build-webkit

Source Overview

The sources for WebKit are in the Sources/ directory. There is also a Tools/ directory where you will find HaikuLauncher, the minimal browser used for testing, as well as other tools for the unit tests.

The Sources are split in several directories (lower to higher layer):

  • WTF is the low-level platform abstraction. It provides threads, shared memory, etc
  • JavaScriptCore is the javascript engine, which can be built standalone as the jsc executable.
  • WebCore is the actual code of the web engine, including the HTTP request system, HTML parser, CSS interpreter, etc.
  • WebKit is the WebKit2 code, with the main() function for the different processes, the communication channels between them, etc.
  • WebKitLegacy is the "legacy" single-process code.

All of these (maybe except JavascriptCore) have some amount of platform-specific code. In WTF, for obvious reasons. In WebCore, for all the HTTP request (soup, curl, haiku, ...), rendering (cairo, freetype, ...), and any other platform specific things at this level. In WebKitLegacy and WebKit, for the APIs exposed to application willing to embed an HTML view or the like.

So, the main directories for the Haiku-specific sources are: Source/WebCore/platform/graphics/haiku ; Source/WebCore/platform/network/haiku ; Source/WebKitLegacy/haiku . There are a few additional files and in some cases specific code in files shared between platforms.

Source Tree

  • Tools/
    • HaikuLauncher/ - Test browser for WebKitLegacy
    • MiniBrowser/haiku/ - Test browser for WebKit2
    • Scripts/check-webkit-style - Checks coding style
  • Source/
    • cmake/ - The core files of the build system
      • OptionsHaiku.cmake
    • JavaScriptCore/ - Runs JavaScript
    • WTF/ - A kind of standard library. Contains string utilities, random number generators, etc.
      • wtf/haiku/
        • RunLoopHaiku.cpp - Contains our implementation of the run loop
    • WebCore/ - The back-end for almost everything web-related
      • PlatformHaiku.cmake - The index to everything Haiku-specific in this directory
      • platform/haiku/
        • DragDataHaiku.cpp
        • MainThreadSharedTimerHaiku.cpp
        • PlatformKeyboardEventHaiku.cpp
        • PlatformMouseEventHaiku.cpp
        • SoundHaiku.cpp
      • platform/graphics/haiku/
        • BitmapImageHaiku.cpp
        • FloatPointHaiku.cpp
        • FontHaiku.cpp
        • ShareableBitmapHaiku.cpp
        • GraphicsLayerHaiku.cpp
    • WebKit/ - The new API that splits the engine across multiple processes.
      • PlatformHaiku.cmake - The index to everything Haiku-specific in this directory
      • UIProcess/ - Everything related to the ui process.
        • API/haiku/ - Home of WebKit2's API
          • WebView.cpp
          • misc. support classes
        • haiku/
          • BackingStoreHaiku.cpp - Holds the rendered web page
      • WebProcess/ - Everything related to the web process. The web page runs inside of this process.
        • haiku/
          • WebProcessMainHaiku.cpp - This contains is the entry-point for WebProcess.
          • WebProcessHaiku.cpp
      • NetworkProcess/ - Everything related to the network process. This does the networking.
      • Shared/ - Code shared across the three processes
        • CoordinatedGraphics/ - Allows WebProcess to draw and UIProcess to display
        • haiku/
          • NativeWebMouseEventHaiku.cpp
          • ProcessExecutablePathHaiku.cpp
      • Platform/ - Also code shared across the three processes?
        • IPC/ - Allows the three processes to communicate with each other
          • haiku/
          • unix/ - Yes, we use UNIX sockets for IPC.
    • WebKitLegacy/ - The old API. It runs everything in a single process.

[What is WebKit?](​https://github.com/WebKit/WebKit/blob/main/Introduction.md#what-is-webkit) also has a nice explanation for some of the folders.

=Other ports =

As you browse the directory tree, you'll see several folders over and over again in different directories. These contain technology-specific code. They can contain inspiration for how to implement unimplemented functions on Haiku.

Some of the folders you'll find repeated across WebKit relate to the ports of WebKit. They are

Here are some of the other folders. They don't relate directly with any of the ports, but are used in some of them:

See also:

Other Notes

PLATFORM vs HAVE vs USE vs OS

Quite often in the code, you'll see #if PLATFORM(HAIKU) or #if OS(HAIKU). They're all quite similar, but there is a way to use them properly. Source/WTF/wtf/Platform.h's comments explain when to use these quite nicely.

Rendering

### Coordinated graphics

As far as I've been able to figure out, coordinated graphics refers to WebProcess and UIProcess coordinating graphics with each other. The UI process has to tell the web process about resizing, scrolling, etc. and the web process has to do the actual painting and then tell the UI process to update what has been displayed.

A nice overview of coordinated graphics (and how rendering is done in general) is given at ​https://www.chromium.org/developers/design-documents/gpu-accelerated-compositing-in-chrome/. Yes, it's for chromium, but it matches what happens in WebKit *very* closely. Also see ​https://trac.webkit.org/wiki/CoordinatedGraphicsSystem

Philosophy of WebKit Porting

There is usually little subclassing. Usually, a single .h file defines the API and each platform has the matching .cpp file implementing it. This means the .h may need to have some per platform #if when there are fields or methods specific to one or another platform. The idea is that this saves vtable overhead when there is going to be only one implementation compiled in.

Logging

Logs are not printed to the console, but to a special program called DevConsole.

To facilitate debugging with multiple processes, logging is done using the DevConsole tool. This allows clearly tagging each log with the originating process (especially useful for WebKit2 where there are multiple processes).

Logging can be controlled using the WEBKIT_DEBUG environment variable. The default is to have all logs disabled. You can enable everythin by setting the variable to "all", or enable specific debug sources. Most logs require some compile time options as well.

([source](​https://github.com/haiku/haikuwebkit/?tab=readme-ov-file#logging))

Further reading

Note: See TracWiki for help on using the wiki.