Chromium on Wayland Desktop (BlinkOn 7)
2 likes11,185 views
Igalia is working on enabling Chromium to run natively on Wayland-based Linux systems by improving the Ozone/Wayland implementation. There are ongoing discussions around implementing external window mode in Ozone to allow Chromium windows to be separate from the host desktop, as well as splitting the UI and GPU components into separate processes as in ChromeOS. Igalia is focused on changing the Mus demo to support external window mode and getting Chromium to launch in this mode on Linux. Further work is also needed on desktop integration and using Mojo for inter-process communication in Ozone/Wayland.
Chromium on Wayland Desktop (BlinkOn 7)
- 1. Chromium on Wayland Desktop (brainstorm) BlinkOn7 Antonio Gomes & Frédéric Wang Igalia
- 2. Agenda ● Who is Igalia? ● Motivation ● Background ● Discussion
- 3. Who is Igalia? ● Worker-owned, employee-run open source consultancy company, based in Spain. ○ 55 employees around the world. ● Areas ○ WebKit, Chromium/Blink and Servo expertise. ○ JavaScript engines / Compilers (V8, JSC), Multimedia, Graphics (Mesa), Networking, Accessibility.
- 4. Motivation ● Being able to run Chromium natively in Wayland-based systems will leverage its adoption in a variety of systems / environments. − Fedora 25 is shipping Wayland by default. − Major GUI Toolkits have built-in support, including Qt 5, Gtk+, Clutter, EFL. − Support from AGL, GENIVI (automotive industry consortium for IVI), Jolla, Raspberry Pi, Tizen.
- 5. Background
- 6. Background ● Ozone project − Set of C++ classes for abstracting different window systems on Linux. − It provides abstraction for the construction of accelerated surfaces underlying Aura UI framework, input devices assignment and event handling. − //ui/ozone/, //ui/events/ozone/ and //ui/base/cursor/ozone/ ● Backends: − DRM/GBM − x11 − wayland − cast − headless
- 7. Background ● Ozone/Wayland (by Intel / 01.org) − Off trunk. − In “maintenance mode” - m49 (december/2015). − Good community adoption. ● Ozone/Wayland (ToT) − Partially upstreamed, but lacked functionality if compared to Intel’s implementation. − ChromeOS / mus+ash oriented. − (used to have an) Outdated documentation. − Limited buildbot coverage.
- 8. Background ● May/16 – start experimenting with Chromium/Ozone/Wayland. ○ Ported part of the code from 01.org to ToT. Internal “investment” ● content_shell ozone/wayland
- 9. Background ● Igalia got in touch with Google/Chromium developers to understand the plans for ui/ozone/platforms/wayland ○ figured about the exosphere project and ChromeOS plans for mash ■ //components/exo/ ■ //mash ○ figured that the original “desktop integration” approach taken by 01.org did not comply with the way future Linux desktop Chrome was planned.
- 10. Background Browser process desktop integration (ozone) Renderer process GPU process ozone platform wayland connection IPC Browser process Renderer process UI process desktop integration (mus) ozone platform wayland connection Mojo x11 wayland Mus Linux desktop integration Gpu service (thread) Linux desktop integration (01.org)
- 11. Background ● Sep-Oct/16 ○ Bringing up of Ozone/Wayland. ○ Start experimenting with “Ozone != ChromeOS”. ○ Design discussions with Robert Kroeger. ○ Buildbots ○ Documentation External “investment”
- 12. Background ● Nov-Dec/16 − CES demo: Linux/AGL/Wayland ; R-Car M3
- 13. Background ● Nov-Dec/16 − Performance on BrowserBench GPU tests
- 14. Background ● Since Jan/17 − //mash/simple_wm − analysis of window classes
- 15. Discussions
- 16. Discussion: Internal vs External ● Internal-window mode ○ All the aura windows in the system end up sharing a single display. ○ All the ash and Chrome aura windows are embedded within a single top-level acceleratedWidget. ● External-window mode ○ What is the status today? ■ robert: unsure if code works/builds today. ○ Where is this in the code? ■ robert: entry point is WindowTreeHostFactory class − Do we have existing tests? ■ robert: No. mus_demo needs to be extended.
- 17. Discussion: Internal vs External ● Robert proposes a two-steps approach: ● Implementing external window mode in ChromeOS/Ozone. ● Expand the support for non-ChromeOS Ozone builds. After talking to sky@ et al, it was agreed with rjkroege@ that this is not the best way to approach the problem. Alternatively, sky@ proposed to work this out directly on LinuxOS/Ozone builds.
- 18. Discussion: Internal vs External ● LinuxOS ○ 1 “accelerated widget” per top-level mus window ■ chrome/mus ○ Create a new “desktop-stub” replacement for Ash? ■ Desktop integration. ■ In essence, a subset of functionality currently provided by Ash is delegated to the native window system. ■ //src/mash/simple_wm ? ● robert: no. ○ new flag, sibling to –mash? ■ robert: yes
- 19. Discussion: Mus/LinuxOS status ● Today ○ Ozone == ChromeOS ○ mus+ash == ChromeOS ● TBD ○ On LinuxOS, Ozone != mus+ash ■ Chrome/Mus ■ USE_X11 not to be defined ■ it ~works: builds / launches ● mix of _mus and _ozone classes are being used
- 20. Discussion: Mus/LinuxOS plan ● Change Mus demo to work on external window mode. ○ Ongoing: Frederic / Antonio. ○ services/ui/demo/ (help from @kylechar) ■ WindowTreeHostFactory ■ ScreenManagerOzoneExternal (no delegate) ■ ui::Service creates ws::Display ■ rework internal window mode assumptions in the code. ● Change Chrome to launch in Mus external window mode. ○ Chrome today launches the same way it ought to, for Chrome/Mus. ● Continue with desktop integration work (feature completion).
- 21. Discussion: UI / GPU split ● chrome –-mash still runs the UI and GPU components in the same process but separate threads. − Future: musws and musgpu in separate processes ■ https://crbug.com/643746 ● Mojo-fication of Ozone/Wayland − Use similar approach than Ozone DRM/GBM (ChromeOS)? − GBM surface ■ robert: to be discussed later.