The path towards richer colors in Chromium

Presenter: Felipe Erias (Igalia)
Duration: 7 min
Slides: download

All talks

Slides & video

Hello.

My name is Felipe Erias

and I am part of the web platform team at Igalia.

Today, I'm going to talk about how the Chromium browser paints colors and what it would take for it to support richer color spaces in the web in the future.

As you know, there are ongoing efforts to add that support to different components of the web platform.

For example, there is already pretty good support for images that use a colored space other than standard RGB.

That's another example in Chromium, that is now an intendt to experiment with additional color spaces in canvas, WebGL, WebGPU.

In this talk I am going to focus specifically on adding support for richer colors in HTML and CSS.

The reference specification for this is the CSS color module.

Among other things, this spec defines a color function that lets the author explicitly indicate the desired color space of a color.

It also defines the Lab and LCH functions to specify colors in the Lab color space, which follows human perception.

It also provides detailed control over how interpolation happens as well as many other features.

Now about Chromium, as you know, it is the free software portion of the Chrome and Edge web browsers.

The web engine inside of it is called Blink and it implements the web platform standards that basically describe how to turn web contents into pictures on the screen.

Blink is a fork of WebKit, which is the web engine used by Safari and others.

It creates a rendering pipeline that takes web sources as input, pages to style sheets, and so on.

Parses them, applies the styles, defines geometry, arranges the content into layers and tiles, paints those and sends them over to be displayed.

This job of actually painting those pictures is carried out by a multi-platform graphics library called Skia.

In Chromium there is already some level of color management, and also support for media queries, and better color profiles, images, and so on.

But there isn't yet support for using richer color spaces with individual web elements.

Within Blink, CSS colors are parsed and stored into a smaller structure, just 32 bits.

That is eight bits per RGB color channel plus alpha.

These colors are eventually handed over to the Skia library to carry out the actual drawing.

Skia uses its own similar 32 bit format which means that throughout Blinks rendering pipeline, colors are represented using only 32 bits.

And this limits the precision and the richness of the colors that can be used and displayed in websites.

Interestingly Skia does not have the same limits in color precision and range as Blink does.

Internally it has a format for high precision colors that holds four float values.

It is also able to take color spaces into account.

Much of this clear API is already able to take as input a color space and one or more high position colors defining it.

So Skia is able to paint richer colors on hardware that supports them.

This means that if we managed to get that rich color information defined in the web sources at the beginning of the pipeline, all the way to Skia at the end of the pipeline, we will be able to paint those colors correctly on the screen.

So that would be our first goal.

There are a couple things worth mentioning here.

First, Skia's representation of high precision colors still uses an RGBA structure.

So out of the box is clear does not support other formats like Lab.

And secondly, the CSS Color spec provides ways to specify interpolation color space for gradients, transitions, et cetera.

Blink relies on Skia for this, but Skia will always use the color space where the source colors have been defined, and does not support interpolating in a different space.

Seeing as one of the challenges in Blink is to be able to store and handle colors with higher precision, and Blink is related to WebKit, we could look at WebKit for AVS I would how to do that.

Internally, WebKit supports a high precision representation of colors, that it stores for float values plus a color space, and Lab is one of those spaces that may be used to define colors in WebKit.

Having this support for higher precision colors has already made it possible to implement several features in WebKit, like support for the display P3 in gamut, and the Lab and LCH CSS functions.

Unlike Chromium, WebKit uses the platforms graphic libraries directly.

So support for displaying the colors beyond the standard RGB gamut may not be available in all platforms.

In summary, the first step to supporting richer CSS colors in Chromium is to add a way to represent higher precision colors and colors basis.

This information is to be used throughout the rendering pipeline, so those colors be correctly painted in hardware supporting why they're colored (indistinct) For web authors it is important that both of these features are in place at the same time, so they can rely on the new functionality provided by the CSS Color spec.

This work is not necessarily straight forward because it would touch a lot of different components, and it might also cut on the impact of memory, on performance, on how painting formation is recorded and used, et cetera.

When that higher precision representation is in place, then we could look into implementing the features in the CSS color spec, like the Lab and LCH functions, or the ability to use different interpolations color spaces.

I hope that with this talk, you've got a better understanding of the scope of the work that will be needed in Chromium.

I see this as some of the first steps in a long road to increase the exposability of the web platform and to why then the range of tools that are available to authors when creating the web.

Thank you very much for your attention and thank you also to the W3C and everybody involved in organizing this workshop.

Thank you very much.

All talks