Today I am excited to announce the successful porting of Chromium to the Mir Display Server. First of course, the obligatory video: a full Chromium browser session running under Mir.http://youtu.be/umuNhpass4Y
Branch is available on GitHub: https://github.com/racarr-ubuntu/ozone-mir
As an engineer on the Mir team, it is exciting to see our work (and the work of many others) validated by the silky smooth performance of even an initial port.
As an Ubuntu developer, focused on the Ubuntu Touch mobile story, this is even more exciting though! Chromium running on Mir is the first and biggest step towards running Chromium in Unity 8, ensuring a diverse browser ecosystem for the future of Ubuntu.
For the technically minded and curious, this work comprises an Ozone port. One step deeper down the rabbit hole Ozone comprises a toolkit abstraction Layer for Aura. We can think about Ozone for Aura much the way we think of QPA for Qt. Of course as many of you have heard before ’There are unique requirements’. Ozone's design is influenced heavily by the multi process architecture of Chromium and the requirements of ChromeOS.
Consider the case of the Ozone DRM backend. For ChromeOS, this can allow the Chromium GPU process to speak directly to the kernel graphics layer, and effectively Chromium itself becomes the system compositor. On the other hand, when Chromium runs as an application on other operating systems, clearly it must speak to the system display server.
In order to grow this flexibility without exhaustive top down design Ozone has thus far left much of the GPU process side interface unspecified. Individual ports are responsible for defining control protocol between GPU process and Host Process and implementation on GPU process side.
By now most readers will be familiar with the excellent work by Intel and contributors in creating Ozone Wayland. Initial investigation in to Ozone Mir quickly lead to the observation that a large amount of code would need to be duplicated between them. In order to try to improve this situation, we have instead based our Ozone Mir work off of Ozone Wayland. Ozone Mir creates a new set of interfaces on the GPU process side abstracting the idea of utilizing an external EGL compositor. This results in a layer much more similar to conventional toolkit porting layers, and we hope that one day something similar can be used by all ports of Ozone to an external EGL windowing system.
Moving forward we are engaging with the Chrome team and Ozone Wayland engineers to develop a plan to move such a layer of interfaces upstream, enabling an easy life of collaboration for Ozone Wayland and Mir.
[See, Architectural Interludes: The GPU Process]
 Well, at least input and window management protocol, the rendering protocol is built in.
 This model is likely suitable for X11, Mir, Wayland, perhaps even SurfaceFlinger. Of course OzoneDRM will not use these interfaces.