the Chromium logo

The Chromium Projects
Teams >

Rendering Core

The rendering core team is a long-term engineering team that owns the overall rendering pipeline and most of the core rendering stages. Specifically style, layout, compositing, and paint. The team is also responsible for text, fonts, editing, canvas, images, hit testing, and SVG.

The team is made up of contributors from many different companies and see regular contributions from many more as well as from individual contributors.

Team Charter

The rendering core team is focused on the architectural principles of reliability, performance and extensibility of the core rendering technologies of the web: HTML, DOM and CSS. We also make sure to satisfy top requests from customers. Our primary customers are web developers and other teams within Chrome which build features on top of rendering.

Priorities

Scalable Performance

Reliability

Extensibility

Ongoing Projects

List of ongoing major projects owned by the team or involving multiple team members.

Organization

Team organization and communication.

Mailing lists

We use a set of public mailing list for technical discussions, questions, and announcements. Access is currently limited to subscribers but anyone may join by posting to the relevant list or following the web archives links below. Once subscribed the full historic archives are available.

Bi-Weekly Meeting

There is bi-weekly meeting held over video conference every second Tuesday open to all team members, the meeting notes of which are available below and sent out to the public mailing list. If you're interested in participating please talk to Chris and he'll share instructions.

Current schedule:

Meeting notes are public and are sent to rendering-core-dev, they're also available in this document: Meeting notes.

Slack

There is also a set of dedicated slack channels for the team. For logistical reasons these are limited to team members and collaborators. Please talk to one of the team members and they'll get you added as needed.

Team Members

Adenilson Cavalcanti adenilson.cavalcanti - ARM San Jose - Performance

Anders Hartvoll Ruud andruud - Google Oslo - Style, Houdini

Chris Harrelson (lead) chrishtr - Google - San Francisco - All areas

David Baron - dbaron - Google Maryland (Remote) - Paint

David Grogan - dgrogan Google San Francisco Layout, Tables, Flexbox

Dominik Röttsches - drott Google Helsinki - Text, Fonts

Fredrik Söderquist fs - Opera Linköping - SVG

Frédéric Wang - fwang - Igalia Paris - Layout, MathML

Ian Kilpatrick (lead) ikilpatrick - Google Mountain View - Layout

Javier Fernandez jfernandez Igalia - A Coruña - Style, Layout, Grid

Joey Arhar jarhar - Google San Francisco - DOM

Kent Tamura tkent - Google Tokyo - Layout, Form controls

Koji Ishii kojii - Google Tokyo - Layout, Text, Fonts

Manuel Rego rego - Igalia Vigo - Layout, Grid

Mason Freed (lead) masonf - Google San Francisco - DOM

Morten Stenshorne mstensho - Google Oslo - Layout, Fragmentation, MultiCol

Oriol Brufau obrufau - Igalia Barcelona - Style, Layout, Grid

Philip Rogers pdr - Google San Francisco - Paint

Richard Townsend richard.townsend - ARM San Jose - Layout, Performance

Rob Buis rbuis - Igalia Hamburg - Layout, MathML

Rune Lillesveen (lead) futhark - Google Oslo - Style

Stefan Zager szager - Google San Francisco - Paint

Steinar H. Gunderson sesse - Google Oslo - Style

Vladimir Levin vmpstr - Google Waterloo - Async

Xianzhu Wang wangxianzhu - Google Mountain View - Paint

Xiaocheng Hu xiaochengh - Google Mountain View - Style

Contributing

If you're interested in getting involved and contributing to rendering there are many ways you could help and we'd love to have you. These range from filing good bug reports to creating test cases, reducing and triaging failures, fixing bugs and implementing new functionality.

Please see the chromium getting involved guide for generic advice and to help you get set up.

A good way to get started is to fix an existing bug. Bug fixes tend to be limited in scope, uncontroversial, and easy to evaluate.

Going through the bug database to find a suitable bug is quite a daunting task though. To make it a little easier we try to maintain a list of bugs that we think are suitable starter bugs. Those bugs are marked with a GoodFirstBug label. Use the following queries to see GoodFirstBug in the style & layout and paint & compositing components respectively. If you prefer, the following queries will show all open bugs in the respective bucket: style & layout, paint & compositing.

Documentation

For a high-level overview of the rendering pipeline please see the Life of a Pixel (slide deck) talk that Steve Kobes gave a little while ago. It gives a very good overview and explains how the different steps in the pipeline work and interact with each other.

For more in-depth documentation about specific rendering stages see the relevant markdown files checked into the main source tree. The README.md file in each top level directory is a good starting point. Some of the key documents are linked below.

Debugging Blink objects

Debugging Firefox/Gecko objects

Design Documents

Each new feature and all major projects require a design document before the implementation work may commence. These documents are updated during the implementation phase and provides a detailed explanation of the feature or project as well as the history and the motivation.

Please add new design documents to the bottom of this list. Make sure they're world readable and, if possible, grant comment privileges to edit-bug-access@chromium.org rather than Anyone with a chromium.org account as not all contributors have chromium.org accounts.

Presentations

Google-internal design documents (aim is to migrate them to the list above; on request we can try to make part/all public)

Font Matching by Full Font Name (2019)

Bug & Triage Policy

The rendering core team is responsible for all bugs for the components listed below, including sub-components . Our policy is that all new bugs are to be triaged within a week of being filed and all P-0 and P-1 bugs are to be fixed in time for the next release. Failures to meet the policy is tracked in our weekly meeting and shared as part of the meeting notes

Policy

  1. Triage all bugs within 7 days.
  2. Fix P0 bugs within 15 days.
  3. Fix P1 regression bugs within 15 days.
  4. Re-triage all bugs every 365 days.