 Good evening everybody, my name is Maxim and I'm a software engineer at Igalea company and today I'm going to present to you our project which is called Chromium's Way to Wealth. First of all I'm going to talk about Igalea company, I will give some information about us, then I will proceed with the goals and the motivations behind the project. I will give some background, give the developments over you, what we have done, what we are doing now, what we are going to do next and of course I will do some demonstration. So Igalea is a private worker on the company. We run a consultancy business in open source area and we are based in Galicia Spain in a city called Carunia, it's in the northwest of Spain and currently we are 62 employees around the globe. Half of us work from Spain and another half work remotely from other parts of the world. And the main areas that we work on are Chromium, Blink, WebKit, server, we are also a member of W3C community and we contribute to web standards. We do work on compilers, JavaScript engines like V8 and JavaScript core runtime language runtime. Also we do multimedia stuff like Gstreamer multimedia toolkit, kernel development, networking, graphics like method drivers, accessibility, visualization and cloud. And on the picture you can see our web engines hackfest that we host every year and this one was hosted last year in October. So this map shows how we are distributed. Some of us work from Europe, Spain, Finland, Denmark, UK, also from USA, Brazil, Chile and South Korea. So what's the goal behind the project? The goal is to be able to run Chromium natively on any Weyland based system. So if there is a system which runs Weyland there should be no limitations or impedances to run Chromium on it. And what motivated us to do that project is that Weyland is actually quite a major solution nowadays and we think it has a better design in a sense of security, better design support and what is more it's a well nowadays good solution to the X window in the system. Also there is a quite big demand from different industries like Automotive or Mobile and Desktop. And to name a few those are from the Automotive site, for example Automotive Great Linux, Genevieve, Volvo. From the Mobile site there are Finnish company called YOLLA, Tizen as well as QT, Toki, JDK and on Desktop site there are Ubuntu, Debian which started to ship Weyland. As the background so where the Ozone Weyland project come from. So first of all it was done by Intel company 01.org organization and it used back at the time Ozone project which was and is still part of the Chromium project. And it's an abstraction layer underneath the OR toolkit to construct the accelerated surfaces. And the back ends it supported the DRI which became DRM utilizing the GBM for the Chrome OS operating system. So Weyland took this approach, this project and started to develop Weyland support of the trunk for Linux operating system. And to give you a minimalistic view how Desktop integration looks like for the stock Chromium I have a diagram here. So there is a browser process and render process which has some kind of JavaScript HTML stuff computation and the sandbox GPU process. And inside the browser process there is a so called Desktop integration which has toolkits and graphics platform related stuff like X11 bits and Windows. So they took that approach and added Ozone Weyland siblings inside the Desktop integration. On the other side there was a browser GPU process which had Weyland connection and everything was communicating using old IPC APIs. So we can treat this project quite successful because there was a good community adoption. Many companies took it to ship in their project as well. But eventually it came to the maintenance month in December 2015. And back at the time the Chromium version was M49 and today is M66 which is 17 miles in gap. So it means that that lacks of some security, you know, box fixings, all other box fixings and some of the functionality losses. So in the meanwhile the Ozone layer became to something else and it supported and it get new backends like X11 and Weyland. But was the problem solved? No it wasn't. Because the original Desktop integration which was taken didn't comply with the foreseen Desktop integration in Google. So as you remember this is the approach that Intel took. But now there is another design called Mass Linux integration for Desktop. So in the Desktop integration there is now our mass platform independent integration which communicates with the new service called UI service using the module APIs which are the newer IPC APIs in the Chromium browser. Inside that we can see the GPU service hosted by the UI service and the Ozone layer is now underneath the UI service. And it has Weyland and X11 backends. And to see more, nowadays there is another work happening in Chromium, so-called visual service which is about to have GL heat tasting and compositing in a different process. And it will also host GPU in another process as well which will give additional 15 percent of performance. So Ozone project evolved to the obstruction layer underneath the UI service instead. And it supported back such backends as DRM, X11 and Weyland but for the Chrome OS. For the Linux we still needed to do something else to be able to run it just out of the box. So how we proceed with the project? So in September 2016 we brought the Weyland back-end to the tip of the trunk and started experimenting so that Ozone is not Chrome OS. On the picture you can see how it looked like. So at the bottom there is a Chrome OS specific widget which is not acceptable for the Linux version of Chromium. We also added documentation for the Ozone and set up a build bot in the upstream. Then in the cooperation with Google we came up with two expressions. The first one was internal window mode which is about having Chromium for Chrome OS which runs a window manager inside and the screen manager. And that window had only one accelerated widget and then it was Aura which drove different windows inside that one accelerated widget. So user didn't interact with the host operating system window as itself. And then there is another expression called external window mode. It's the mode when there is no internal window manager and there are different accelerated widgets created for each new Chrome window. Let it be for example tool tips, menus and any other Chromium widgets, Chromium windows. And now user manipulates the accelerated widgets via the host operating system window to maximize them, minimize them, resize, drag or full screen. In internal window mode is the internal window manager which does all this stuff. And of course in external window mode there is no such a thing as a screen manager. So to give you an overview how it looked like in the beginning, here is a demo how it run on the Renaissance M3 board back at the time in 2016. So as you can see they bounce both demo is not smooth enough and it lacks so far performance. Here is also scrolling which is not that smooth enough. And of course the work still needed to be continued. We also forked the meta browser and implemented our meta browser recipe so that any Octobase system could build the Chromium and use it there. So what we needed to do in order to bring external window mode. So we needed to modify internal window mode so that it created for each new top level window an accelerated widget. And we also needed to extend the mass so called module UI service and also in order to support external window mode. And we needed to ensure that there were no major functionality loses or performance loses compared to the stock Chromium. To start with we begin with mass demo. So this is the demo which actually exercised the UI service. So we needed to extend it in such a way so that it created different windows with different accelerated widgets and draw some content inside that. We also needed to rework the internal window mode code assumptions. For example in Chrome OS there is one to one relationship of the display on the UI service side and the display on the Aura side. For the external window mode the display display on the Aura side actually represented a physical display but the display on the UI side represented actual window, Chromium window or menu window or any other window related to Chromium. So the relation became from one to one to one to many. We also extended mass and ozone to support external window mode as I previously said. And what we needed to do there is to properly handle for example bounds and route the events from ozone to up to the Aura. Also we made it possible to run Chromium with the existing dash-dash mass flag so that UI service would come up. We also added XDJ version 6 support because before that it was only XDJ version 5 support. Keyboard events, auto-repeating, mouse cursor because before that it was the internal window monitor which did this stuff. Also added to support for the touch events. This patch was provided by our friends from Calabra. We added multiple windows support. We started to use built-in window decorations instead of the host provided ones. Implemented window closing support because before that that was the internal window manager which actually did the stuff. We added menus, widgets and tool tips support and allowed user to interact with the windows like maximizing them, minimizing, restoring, making them full screen and so on. We also needed to change the ownership model of some objects. For example representing the states of the windows on the UI side, UI service side. We also implemented keyboard like IME service integration. We did some slightly custom window tree hierarchy so that representations of the window on the aura side would comply with the representation of the windows on the UI service side. We also needed to rework the access policies so that the clients on the aura side would access only the specific windows. It is allowed to access. Of course we worked on stability and hardness of our implementation and made the content shell to be run with mass on Linux. What is the status of the project today? I will show you the video on how it runs on Debian with GNOME shell on Wayland. Let's have a better quality. As you can see this is mass with Ozone platform Wayland back end. It is actually version 66, the most latest one by this day. It supports many tabs. Here is actually HTML5 test and we score 526 points out of 555. All the features which are supported in the development branch in the TUT are supported by our browser as well. We score around 60 FPS in the WebGL demos. Everything is hardware, GPU accelerated. You can see two windows working at the same time. You can ask why I am showing it to you because it is the same chromium. I want to say that it is actually the same chromium but it uses another design and it uses Wayland back end which was impossible before that. Here is also another demo with X11 back end but I am not going to present it here. The idea is that while we were working on extending UI service to be run on externally mode, we also added support to run both Wayland and X11 back ends which means that you do not need to get another chromium binary for that one. You will just need one binary and using an Ozone platform flag you will specify which back end you are going to use. If you remember, there was another video which I showed previously how it run on the Renaissance Aircar M3 board using the bounce symbols. Nowadays it is pretty smooth given that Renaissance M3 board runs only on two cores because other four cores are blocked and that is under development. So a few words about the project itself. Currently the project is hosted on GitHub in the Dubstriper repository. We have well defined contribution policy like with you peer reviews on each commit. Also we have internal build boat running our existing tests. For example, the services unit tests like some UI related tests, Ozone unit tests, browser tests, content browser tests and we have 98% of the pass rate. Also we run content unit tests and why we need internal build boat is that because we want to ensure that whenever we implement a new feature or do any changes, there are no regressions. We also have well defined weekly rebasing strategy and we continuously clean our GitHub history. For example, when we implement a new feature and we need to have some kind of change for that one, we commit a new fix-up and whenever we do a rebasing, we squash all the fix-ups so that the history keeps clean. And when we upstream patches to the upstream repositories, we do not carry forward flags so that next week when we do a rebasing, we do not add this commit which might have been changed in the upstream while we were upstreaming it because a Hormone community might have requested to change the patch a bit. Also we do periodic sync-ups with Google so that we comply with their plans. If you are interested in more design and more deep, you can follow the documentation in the Google docs and this presentation is available on the Fosnum website so that you can follow from there. So what's left to do with this project? We still need to implement drag and drop support and we lack of clipboard support between Hormone and host. For example, you can do copy pasting inside the Hormone window but not outside that one. Also we still lack multi-screen support and we do not support non-English layouts. Also we continuously ensure that there are no feature losses and a major performance penalty is seen if we compare to the stock Hormone. Also we do integration inside Automotive Grid Linux and this job is started and done by IoT but whenever they request our help, we provide it to them. Also we plan to release desktop installers in a sense of our RPM packages and one of the important things is to continue upstreaming our projects to the tip of the trunk. Also we are planning to enable more tests in the upstream build bot along with upstreaming and as I previously said, we still need to decouple mass from visual service so that the GPU process will be run not as a threat inside the UI service but as a separate process. Thank you for your attention. The project is done by Igalia and sponsored by Renaissance. Whether you have any questions, you can contact me, Maxim or my colleague Antonio from Igalia.