By Maksim Sisov. Slides at https://docs.google.com/presentation/d/13D5M9ZDGM-i33GDjMFLFrPHWRvYJcZvai3zI4RQ0tDM/edit#slide=id.p1 (c) BlinkOn 10 Toronto, Ontario (Canada) April 09 - 10, 2019 https://docs.google.com/document/u/1/d/e/2PACX-1vTgBrqyQ4KCchsymvssri1pN1BkOg3sEqHThqhvFDl9-zl-hLx1S5c8sc5gaZ_VzKEVaYj94H3m1vso/pub#h.igsyfaa103a0

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