Chrome/Chromium on Wayland: The Waylandification project.
If you already know what Ozone is, then I am happy to tell you that Chromium for Linux includes Ozone by default now and can be enabled with runtime command line flags. If you are interested in trying Chrome/Chromium with native Wayland support, you are encouraged to download Google Chrome for developers and try Ozone/Wayland by running the browser with the following command line flags – ‘–enable-features=UseOzonePlatform –ozone-platform=wayland’.
If you don’t know what Ozone is, here’s a brief explanation, before I talk about the history, status and design of this effort.
What is Ozone?
The very first thing that one may think about when they hear “Ozone” is the gas or a thin layer of the Earth’s atmosphere. Well… it is partly correct. In the case of Chromium, it is a platform abstraction layer.I will not go into many details, but here is the description of that layer from Chromium’s documentation about Ozone –
“Ozone is a platform abstraction layer beneath Aura, Chromium’s platform independent windowing system, that is used for low level input and graphics. Once complete, the abstraction will support underlying systems ranging from embedded SoC targets to new X11-alternative window systems on Linux such as Wayland or Mir to bring up Aura Chromium by providing an implementation of the platform interface.”.
The Summary of the Design of Ozone/Wayland
It has been a long time since Antonio Gomes started to work on this project. It started as a research project for our customer – Renesas Electronics, and was based on a former abstraction project with another clever name, “mus+ash” (pronounced “mustache”, you can read more about that here – Chromium, ozone, wayland and beyond).Since that time, the project has been moved to downstream and back to upstream (because of some unknowns related to the “mus+ash”) and the design of Ozone integration has also been changed.
Currently, the Aura/Platform classes are injected into the Browser process and communicate directly with the underlying Ozone platforms including Wayland. In the browser process, Wayland creates a connection with a Wayland compositor, while in the GPU process, it only draws pixels into the created DMABUFs and neither receives events nor creates surfaces.
Migrating Away From X11-only Legacy Backend.
It is worth mentioning that Igalia has been working on both Ozone/X11 and Ozone/Wayland.Since June 2020, we have been working on switching Ozone for Linux from needing to be done at compile time to being choosable at runtime. At the moment, one can try Ozone by running Chrome downloaded from the development channel with the ‘–enable-features=UseOzonePlatform –ozone-platform=wayland/x11’ runtime flags.
That approach is allowing us to gather a bigger audience of users who are willing to test the Ozone capabilities, but also achieve a better feature parity between non-Ozone/X11 and Ozone/X11/Wayland.
That is, most of the features and code paths are shared between the two implementations, and the paths that are not compatible with Ozone are being refactored at the moment.
Once all the incompatible paths are refactored ( just a few of them remain) and all the available test suites are enabled on the Linux/Ozone bot, we will start what is known as a “finch trial”. This allows Ozone to be enabled by default for some percentage of users (about 10%). If the finch trial goes well, the percentage of users will be gradually grown to 100% and we will start removing old non”-Ozone/X11 implementation.
Wayland + Tab Drag
If you’ve been trying it out, you might have already noticed that Ozone/Wayland does not support the Tab Drag feature well enough. The problem is the lack of the protocol for this feature.At the moment, my colleague Nick Diego is working on the definition of the protocol for tab drag and implementation of that in Chromium.
Unfortunately, Ozone will fallback to x11/xwayland for compositors that do not support the aforementioned protocol. However, once more and more compositors will support that, Chrome will whitelist those compositors.
I would not go into details of that effort here in this blog post, but just rather leave a link to the design document that Nick has created – Tab Dragging on Ozone/Wayland.
Summary
This blog post was rather a brief summary of the design, feature, and status of the project. Thank you for reading it. Hopefully, when we start a finch trial, I will write another blog telling you how it goes. Bye.Posted: November 20th, 2020 under browsers, chrome, chromium, igalia, ozone, wayland, weston.
Comments: 16
Comments
Comment from Anthony Matarazzo
Time: January 3, 2021, 3:35 pm
I have worked with several versions of linux and finally found gentoo linux. It makes you feel as though you have made a working airplane model that you hold dear, It is amazing the difference in speed and multitasking scheduling. To utilize wayland, one desktop environment is kde, although I am partial to gnome but couldn’t find references for providing a wayland yet. So this is the kde wayland usage.
Question:
——————————————————————————————
Does chrome have a way to tell which backend it is using for compositing? gentoo linux. How to get chrome on gentoo with wayland?
——————————————————————————————
Using wayland for the compositing features does smooth the visual artifacts that occur during full screen window drawing. Less flicker and visual artifacts. As you know you would have to closely study the visual rendering characteristics several minutes between x11 and wayland to actually see the differences. wayland is more synchronized and provides a better illusion that the window is being moved rather than redrawn. This makes way for desktop animations for windows that would be accepted by users.
For gentoo as well, my comparison is the crazygames website showing the playing of a few games. Firefox vs Chrome using x11 and wayland. Chrome performs well enough on x11 that it is acceptable. Firefox on x11 has some large frame misses when full screen updates occur. However, when firefox is run as a wayland client, it performs noticeably better without missing frames.
I wanted to start research the usage of LLVM as a jit for desktop environment. LLVM is underused in the linux project. Imagine having a render loop for the menu system, desktop, and animation window based on settings.
Skia is well suited for this as well as several layers existing is other software but sits atop x11. Gdk, cairo, pango, Gtk, clutter, etc have also solutions but at times not as robust. I will look closer at the skia for creating the surface.
xcb rendering extensions is lower level than skia. cairo has dri support but is not fully supported as per documentation.
Question:
where are some good references for c++ wayland desktops.
Comment from msisov
Time: January 4, 2021, 6:14 am
Q) Does chrome have a way to tell which backend it is using for compositing? gentoo linux.
Nope. I haven’t seen any protocols that would help to identify the compositing server.
Q) How to get chrome on gentoo with wayland?
Run the latest chrome with the following flags – –enable-features=UseOzonePlatform –ozone-platform=wayland
Q) where are some good references for c++ wayland desktops.
https://jan.newmarch.name/Wayland/ProgrammingClient/
https://wayland.freedesktop.org/docs/html/ch01.html
Comment from Richard Kawala
Time: January 5, 2021, 7:50 pm
Thanks for your good work! https://bugs.chromium.org/p/chromium/issues/detail?id=578890, however, makes it hard for an outsider like myself to understand how much work has been done, and how much is still ahead. Bug 578890 lists dozens and dozens of blocking issues. Can I run Chromium on Wayland today? In a few months? Not for years?
Comment from msisov
Time: January 6, 2021, 8:20 am
Yes, you can run it now. Just download official Chrome for Linux and run it with –enable-features=UseOzonePlatform –ozone-platform=wayland flags.
Comment from Damian Kaczmarek
Time: February 17, 2021, 11:19 pm
I tried (openSUSE Tumbleweed) but I am getting this error:
(google-chrome:4836): Gtk-WARNING **: 16:53:10.129: cannot open display: :1
the errors looks as though it is looking for an X server … “google-chrome” with no flags starts just fine – probably in XWayland?
Comment from msisov
Time: March 15, 2021, 6:23 am
What’s version of Chromium you use and how do you start it?
Comment from Suyambu
Time: January 22, 2021, 6:07 am
Hello,
I am not sure if this is right platform to ask this.
I am trying to run chromium with ozone wayland as below using weston. And I see below error.
$./out/Default/chrome –enable-features=UseOzonePlatform –ozone-platform=wayland
[16881:16881:0122/144517.765700:ERROR:wayland_connection.cc(104)] No Wayland shell found
[16881:16881:0122/144517.765707:FATAL:ozone_platform_wayland.cc(185)] Failed to initialize Wayland platform
weston-info gives below one interface and not “zxdg_shell_v6” or “xdg_wm_base”
interface: ‘xdg_shell’, version: 1, name: 13
Am I missing anything. Could you give some advice ?
Comment from msisov
Time: January 22, 2021, 7:39 am
xdg_shell is the very first xdg_shell that Chromium no longer supports.
Comment from Suyambu
Time: January 27, 2021, 4:43 am
Thanks for your reply. I am new to wayland and trying to check this on ubuntu with nvidia gpu. Using weston/mutter compositor didnt help in launching chrome with wayland.
Is there any pre-requisite like any particular ubuntu/gnome version is required to verify this ? I could not find much guide from chromium references too.
It will be a great help if you provide some information on this.
Comment from msisov
Time: January 27, 2021, 7:20 am
nvidia gpu is not supported as they do not support gbm. you can only use sw compositing path with nvidia (–disable-gpu).
Comment from Richard S Kawala
Time: March 14, 2021, 8:15 pm
You mentioned that you’ll need to extend the Wayland protocol in order to support tab dragging. I imagine that it’s a multi-year project to get an approval from the Wayland project for the protocol extension. In the meantime, how much will performance suffer because Chromium/Chrome has to use XWayland?
Comment from msisov
Time: March 15, 2021, 6:26 am
Correct.
We haven’t compared the performance between Wayland and XWayland yet. Though, we did run some tests on Rpi3 with Chromium in Wayland and X11 sessions. Our result was that the webgl aquarium demo showed 24 fps when the browser was running with native Wayland support and 6 fps when the browser was running with native X11 support in X11 session. In both cases, 100 fishes were shown.
https://osseu2020.sched.com/event/eCJr/waylandifying-chromium-from-downstream-to-shipping-maksim-sisov-igalia
https://static.sched.com/hosted_files/osseu2020/b6/Waylandifying%20Chromium%20-%20from%20downstream%20to%20shipping.pdf (slide 28)
Comment from Richard S Kawala
Time: April 9, 2021, 1:40 am
Is it possible to use XWayland to implement tab-dragging, but simultaneously use a non-XWayland compositor to render the page? That is, can you get the performance benefits of Wayland but also implement tab-dragging today?
Comment from msisov
Time: April 9, 2021, 5:08 am
I believe it’s not possible to do.
Comment from Hi-Angel
Time: May 24, 2021, 7:45 am
Thanks!
So, you say Ozone is just an internal abstraction layer. This implies less code duplication, less maintainance effort — that’s fine.
But, does it give anything beyond that? For example: I’m running X11 (not Wayland), is there any reason for me to switch to Ozone?
Bug #1201165 about finch testing Ozone/x11 says, quoting:
> Differences in input latency, frame delay, crashes/minute, and memory usage are all within margin of error (though the sample size is still small)
Does that imply, there’s nothing for me as an X11 user to care about?
Comment from msisov
Time: May 24, 2021, 7:47 am
Correct. Migration of X11 to Ozone is only internal change that mustn’t affect users at all.
Write a comment