Maksim Sisov Blog

The “Ozone” abstraction.

Within Chromium, an abstraction known as “Ozone” has been in development for many years. It is believed to be very important for Chromium’s design that heavily relies on dependency inversion, which helps to isolate high and low level components that communicate through interfaces.

It is also designed with the interface segregation in mind that increases cohesion, which is not that easy to maintain given extremely different requirements that different backends may have, and overall cleanness of the code.

Nowadays both Chromium on Chrome OS and on Linux are the heavy users of Ozone.

Where are we now?

We reached a major milestone this fall.– Ozone became an integral part of Chromium on Linux. The main backend that Chromium uses when runs on Linux is Ozone/X11.

If you ask – “why?”. The answer will be simple – Linux has always been the user of the X Window System and it was a natural choice to continue to use X11. But… via Ozone this time.

Even though, enabling that required major refactoring and thousands of lines of new code, it opened an opportunity to bring other backends into the play – Wayland.

Honestly speaking, Wayland was and is the reason why all this effort exists.
And, if you are interested in more details, I encourage you to checkout my colleague’s blog post – “Ozone: our way to the big change”, which describes the past progress in a little bit more details.

Let’s talk about the current state of Ozone backends in a little more detail.

Ozone/X11

As was said previously, the Ozone/X11 has been released and does not require as much effort as it required before. There is only on task left – a grand final code migration.

You may remember from our previous blog posts that we had to refactor the old legacy X11 path in such a way that both Ozone/X11 and legacy X11 implementations can reuse the same low-level code. To achieve that, all the low-level pieces were placed into common directories – //ui/base/x and //ui/platform_window/x11.

Recently, the old path has been deprecated and removed, and all these low-level details can finally be moved into the //ui/ozone/platform/x11 directory.

However, just few bits left – there are a couple of interactive UI tests that use low-level components directly. These tests will be placed into to the //ui/ozone/platform/x11 directory very soon.

Once that task is completed, all the low-level X11 code I mentioned before will also be moved into the Ozone/X11 folder.

Ozone/Wayland

Wayland is the reason why all this work happened. The implementation is stable enough, and it is used by our several customers in different areas – from automotive to home appliances.

Nowadays, we can call it beta as most of the features have already been implemented. The list includes handling of UI events, window state changes, window management, buffer management, zero-copy and more.

Today, we are working on several performance improvements, better test coverage and better support of different hardware. Moreover, we are adding ANGLE support soon. Vulkan is also part of our plans.

And going forward, the performance improvements that I mentioned are based on delegating most of the compositing to Wayland by sending as many quads as overlays as possible. This approach is better than doing the entire compositing on the Chromium side (this deserves a separate blog post).

What’s next?

We are continuing our work on the Ozone/Wayland area.

There are still many issues to be addressed and new wayland protocols to be written but, thanks to the milestones achieved so far, we are confident we will be building on solid foundations, so it will be a matter of time to have a fully functional native Wayland implementation for Chromium on Linux.