Version 4 (modified by alex, 4 years ago) (diff)


Igalia's focus and goals 2020


Slide Deck

Who we are

  • Worker cooperative with people all over the world
  • Browsers is the main area of work (graphics, multimedia, etc.)
  • We advocate for open source, open standards and secure platforms/software
  • We actively participate in spec definition organizations (e.g. TC39 and W3C)
  • We use WebKit to primarily enable integration of Web content into a wide range of use cases
  • We are invested in helping WebKit remain competitive in those and other cases
  • We support companies in ways that improve WebKit
    • Companies that would use WebKit
    • Companies that want to progress the Web platform

The GTK port

  • Focuses on the Linux desktop.
  • The main use cases are GNOME Web (Epiphany) and applications embedding web views.

The WPE port

  • Widely used in embedded (mainly Linux for now).
  • Designed with performance, small footprint, accelerated content rendering, and simplicity of embedding in mind

The WPE port

  • Primary success in STB deployments
  • Also used in different embedding use-cases: home appliances, in-vehicle information systems, digital signange
  • Alternative to Chromium

API Layer

  • Solid PSON support
  • GTK4 integration for WebKitGTK
  • QtWPE
    • QML wrapper around WPE
  • API additions as required


  • Async scrolling support
    • Needs polish, more code-sharing
  • Graphics pipeline revamp
    • Ongoing, loosening dependence on Cairo
  • WebGL, WebGL2 -- ANGLE-based
    • Likely requires new ANGLE platform
  • WebGPU
    • Depends on Vulkan support (result of graphics pipeline work)



  • GStreamer playbin3 support
    • Improved seek support, stability
  • GstWPE
    • Web content piped to GStreamer-managed pipeline
  • RFC: GStreamer-specific tab in Web Inspector


  • Currently using libwebrtc
  • Problems with hardware decoding integration
  • Evaluating gstwebrtc
    • A more natural fit for our stack


  • Platform support
    • Big rewrite pending to land


  • Platform support
    • Trying to find a good CDM integration solution
  • SVP support


  • libsoup and glib-networking maintainance
    • GLib-based networking stack
  • Client certificate authentication and PKCS #11 support
  • HTTP2 and eventually QUIC+HTTP3

Releases & Dependencies

  • One stable version every six months (in March and September)
  • We branch for the new stable release around one month before the release
  • Only bug fixes and improvements are allowed in stable branches, no new API or features
  • We make several "unstable" releases from trunk during the cycle
    • After branching such releases are release candidates
  • Additional releases from the stable branch after the initial stable release
    • Bug fixes, improvements and security issues

Compiler updates

  • Debian and Ubuntu LTS releases support:
    • (GCC 7 OR Clang 6) AND libstdc++ 7, Ubuntu 18.04 (until April 2021)
    • (GCC 8 OR Clang 7) AND libstdc++ 8, Debian Buster (until late 2022)

Note: At least one compiler from the system has to be able to compile, some distros already use clang to compile WebKitGTK security updates.

We support major Debian releases until one year after the release of the next major version. Same for Ubuntu LTS releases. At the moment:

  • (GCC 7 OR Clang 6) AND libstdc++ 7, the versions in Ubuntu 18.04, will be supported until April 2021 (the next Ubuntu LTS will be released in April 2020).
  • (GCC 8 OR Clang 7) AND libstdc++ 8, the versions in Debian Buster, will be supported until, roughly, late 2022 (the next Debian will be releases in late 2021).

More Information:

WPE compilers

  • Build systems for Linux-based embedded devices often lag even further behind
  • People targeting embedded devices are extremely reluctant to update their system compiler in the middle of product development
  • In many cases future product updates will keep using the same compiler
  • Expensive but usable work-arounds

QA: testing infrastructure

  • We provide and maintain the GTK/WPE/JSCOnly buildbots and EWS:
    • GTK: x86_64 testers. Performance bot
    • WPE: x86_64 testers
    • JSCOnly: ARM64/ARMv7/MIPS testers
  • Plans to add more bots to the testing infrastructure:
    • Address, thread, undefined behavior sanitizers
    • WPE testers in ARMv7/ARM64 architecture
    • WPE performance bot
    • GTK API tester EWS


  • Third-party dependency management is hard
  • Current solution: JHBuild
  • Future solution: Flatpak
    • Can be used as a development environment as well as a release channel

Faster-pace release channels

JSC 32-bit support

  • LLInt, baseline JIT and DFG for ARMv7 and MIPS
  • Enable as many tiers as possible
  • Bug fixes
  • EWS/buildbot
  • Memory and performance work

JSC feature implementation

  • Class features implementation
    • Static/instance class fields
    • Static/instance private methods

Public class feature example

class C {
  field = 1;
  static staticField = 2;

let o = new C();
o.field; // returns 1

C.staticField; // returns 2

Private class feature example

class C {
  #field = 1;
  static #staticField = 2;
  #method() { return this.#field; }

  static #staticMethod() { return this.#staticField; }

  access() {
    this.#method(); // returns 1
    C.#staticMethod(); // returns 2

JSC feature implementation

  • BigInt (not feature complete)
    • Missing TypedArray support
    • Support '++' and '--' operators (including JIT)

Test262 contributions

  • Private methods and class fields
  • BigInt

Web Standards

  • Will not go into much detail for every 2020 Web Standard task.
  • Feel free to ask about details.
  • Listed responsible persons in the slides.
  • The plans are not final yet.


<div class="rightimg"><img width="300" src="images/mathml-core.png" alt="MathML Core"/></div>




  • Lazy image + iframe loading (rbuis)
  • Load prefetch/preload/prenavigate (rbuis)
  • Priority Hints (rbuis)
  • Stale-while-revalidate Cache-control directive (rbuis)
  • Web Package (rbuis)
    • Signed HTTP Exchanges
    • Bundled HTTP Exchanges

Other standards

Web Platform Tests

Making WebKit more interoperable

  • Identify test failures.
    • Bug triaging and gardening
    • Make them pass!
  • Implement missing features.
    • Already imported tests
    • Client requests

Making WebKit more interoperable

  • Synchronize WPT tests.
    • Import existing tests
    • Export new or modified tests
  • Work with the community
    • Standardization groups
    • Web developers / users


  • Are you reviving the Mathml spec also? Yes, fwang is working in modifying it at the same time he works in the new core spec.
  • Sam turned Resize Observer on by default yesterday.
  • how do we get the webkitgtk results? it is still not public, there is a URL but it is going to be there when stable.
  • what 32bits cpus are you using? Arm 32bits usually such as the raspberry pi.
  • What is the main hardware in your products from 32bits CPU? There are multiple clients that provide this kind of Arm and MIPS CPUs in products.
  • What those clientes do with the engine? Runtime for rendering and general browser, for instance STB
  • Security is a big concern in 32bits, that is why general browsing is not safe? Yes, we work trying to improve the security, we use sandboxing usually to try to keep this security problems contained. Also in general clients enable web applications stores for secure webpages that can be loaded
  • Measure the performance improvements with JIT? We use some public available workloads, but also use internal benchmarks based on client applications.
  • Could you abstract a benchmark with those tests? Yes, we could try to abstract that. Currently we have some sample program using our client's framework and we measure the FPS, and on their hardware, we only get usable results with DFG enabled.

Attachments (1)

Download all attachments as: .zip