The document presents an overview of the ozone/wayland project led by Igalia, detailing its design, current status, and future plans. It emphasizes the project's focus on a secure protocol and improved graphics stack for browser frames, with various completed and ongoing features. The future aims include resolving outstanding issues and potentially integrating x11 within the ozone framework for streamlined development in Chromium.

1. Towards shipping Ozone/Wayland
BlinkOn 10 (April/2019)
Toronto, Canada
Maksim Sisov, msisov@

2. Agenda
● About Igalia
● Why Wayland
● High-level Design Overview
● Current Status
● Other Key Concepts
● Wayland with GBM
● Future Plans and Ozone/X11

3. About Igalia
● Worker-owned, employee-run Open Source consultancy
company, based in Galicia, Spain.

4. About Igalia
● ~80 employees around the world.
● Areas
○ Chromium/Blink, WebKit and Servo; W3C member;
○ Compilers, JavaScript engines (V8, JSC);
○ Multimedia, Kernel, Networking;
○ Accessibility, Virtualization & Cloud.

5. About Igalia

6. Why Wayland

7. Why Wayland
● Refined and more secure protocol
○ Sandboxed windows (no keyloggers)
○ Own protocol extensions
● Simple graphics stack
○ Does not provide drawing APIs (shares a DRM handle
instead)
○ Can manage compositing
● Demand from industries
○ Automotive
○ Entertainment
○ Phones

8. High-level Design Overview

9. High-level Design Overview
● Platform independent DesktopWindowTreeHost implementation
for browser frame.
○ Uses PlatformWindow
○ Communicates to Ozone
● Wayland connection in the browser process.
● GPU process uses SurfacelessEGL and GBM.
● Browser process imports Wayland buffers (wl_buffer) and handles
GPU process’ requests to damage and commit buffers.

10. High-level Design Overview

11. Current status

12. Project management status
● Upstreamed all the Ozone/Wayland the patches from the
downstream Igalia repository (about 150 patches since
April/2018)
● Switched the work to be 100% in the upstream
● Moved all the pending issues to Wayland umbrella bug
● Continued keeping V4L2 patches in downstream

13. Features completed/merged
● Wayland IME
● Support for maximize/fullscreen/restore + restore size of
windows
● Window move/resize
● Clipboard support
● Tooltips support
● Non-English layouts support

14. Features completed/merged
● Delegated placement of menu and context windows
● Cursor bitmaps
● Opaque regions
● Session restore
● Multiple displays support
● Drag and Drop support

15. Features completed/merged
● Viz/GPU process support. Including
○ NativePixmap support
○ GpuNativeMemory buffers support
● ZeroCopy support.
● Fixed software rendering path

16. ● File Dialogs
○ WebUI or GTK
○ Design document
● Tab Drag
○ Completed single-window tab dragging
○ Pending to complete tab detach/attach to other window
● HiDPI support
○ No well-defined spec
○ Implementation workarounds for different compositors
○ Dynamic scale change on display relocation
○ 90% complete
● Primary Selection support
Features Pending

17. ● Regression with VizDisplayCompositor enabled
○ Enabled by default since Chromium 73
○ Regressed from 1-20% depending on hardware
○ Blocked sending frames by the submission and
presentation callbacks:
■ Split SwapCompletion and Presentation callbacks
■ Move pending frame logic to the
WaylandBufferManager
■ Use pre-waiting for the frame callback
■ Possibly move Wayland display polling and buffer
management to evdev IO thread
Performance

18. ● Performance gain with opaque region set:
○ Optimization hint for the Wayland compositor
○ 100% performance gain on Raspberry pi3 (30 to 60 FPS)
○ Stable FPS running Aquarium WebGL demo
Performance

19. ● Buildbot running in the Chromium community infrastructure.
● Enabled tests:
○ ozone_unittests
○ services_unittests
Testing

20. ● Based on Chromium 73.0.3683.75 (official channel)
● Contains backported Ozone/Wayland patches
● Merged to OSSystem upstream GitHub repository
Meta-browser

21. Other Key Concepts

22. ● Does not provide global space coordinates
○ Assume the top-level window is located 0,0 in 99% of cases
○ Only local surface coordinates are provided
● Requires placing popup windows (menus, tooltips) relative to the
parent surface
○ Translate bounds from screen coordinates to local surface
coordinates
○ Calculate correct anchor bounds and choose right positioner
anchor
Positioning of Wayland Windows

23. ● WaylandOutput represents one real physical display
● WaylandOutputManager
○ Manages outputs
○ Notifies WaylandScreen
● WaylandScreen
○ Implements PlatformScreen
○ Keeps and manages the list of displays
○ Provides displays to aura::ScreenOzone
Multiple Displays

24. aura::ScreenOzone ui::WaylandScreen
ui::WaylandOutputManager
ui::WaylandOutput
Multiple Displays

25. ● No primary display concept (GetPrimaryDisplay)
○ Use the one nearest to the zero origin
● No most occupied display window concept
(GetDisplayForAcceleratedWidget)
○ Use output listener
○ Assume the very first entered display is the most occupied
● No cursor position in screen coordinates
(GetCursorScreenPoint)
○ Listen to mouse events
○ Store locations in local surface coordinates
○ Return location which is out of the bounds of the largests
window
Multiple Displays

26. Wayland with GBM

27. Wayland with GBM
● Problem
- How to access Wayland surfaces on the browser process
side?
■ Stick with in process gpu mode
■ Use xdg importer/exporter
■ Use libgbm

28. How Buffers Are Created
WaylandSurfaceFactory GbmPixmapWayland
gbm_wrapper
libgbm
WaylandConnectionProxy
WaylandBufferManager
Wayland
Associated mojo pipe

29. How Buffers Are Swapped
GbmSurfacelessWayland WaylandConnectionProxy
WaylandBufferManager
Associated mojo pipe
Wayland
Attach
Damage
Commit
Setup frame callback
Setup presentation
OnScheduleBufferSwap(
gfx::SwapResult,
gfx::PresentationFeedback)

30. How Buffers Are Swapped

31. Splitting Callbacks
GbmSurfacelessWayland WaylandConnectionProxy
WaylandBufferManager
Associated mojo pipe
Wayland
OnSubmission (gfx::SwapResult)
OnPresentation (gfx::PresentationFeedback)

32. Splitting Callbacks
● PassThroughImageTransportSurface needed to be fixed:
Swap[0]
Swap[1]
Swap-Ack[0]
PresentationCallback[0]
Swap-Ack[1]
PresentationCallback[1]
Swap[0]
Swap-Ack[0]
Swap[1]
PresentationCallback[0]
Swap-Ack[1]
PresentationCallback[1]

33. Splitting Callbacks

34. More Improvements
● Switch from the post frame callback wait to pre frame callback
wait.

35. More Improvements

36. Future Plans and Ozone/X11

37. Future Plans
● Complete and upstream pending features
● Resolve open Ozone/Wayland issues
● Add more tests to the linux-ozone-rel buildbot
● Ship Ozone/Wayland as part of the stable Chrome releases

38. Ozone/X11
● Avoid having two paths for X11 and Wayland backends
○ Move X11 under Ozone
○ Decide on LinuxUi
○ Have single CI bot for X11 and Wayland
● Let Chromium choose the Ozone backend

39. Thanks to
tonikitoo@igalia.com - Antonio Gomes
fwang@igalia.com - Frédéric Wang
msisov@igalia.com - Maksim Sisov
jkim@igalia.com - Jeongeun Kim (Julie)
nickdiego@igalia.com - Nick Diego Yamane
adunaev@igalia.com - Alexander Dunaev
rjkroege@chromium.org - Robert Kroeger
spang@chromium.org - Michael Spang
sky@chromium.org - Scott Violet
sadrul@chromium.org - Sadrul Habib Chowdhury
kylechar@chromium.org - Kyle Charbonneau

40. Questions?
msisov@igalia.com - Maksim Sisov
nickdiego@igalia.com - Nick Diego Yamane
adunaev@igalia.com - Alexander Dunaev