Wayland Port
As our strategy of using Chromium as our engine of choice, we need Wayland support as some of our Linux target platforms are using that as the default (please check Roadmap), so we at Intel are committed on doing such changes.
In short, and as a proof-of-concept, we successfully ported content_shell on Wayland to run under Weston (Wayland reference compositor):
Commands for creating windows and the contents are issued by the browser, which uses Views widgets for doing so. These widgets are backed by Aura framework which in turn builds up a scene graph on Chromium composite layer. Based on the windows drawing command, theses layers are scheduled to draw and later paint via Skia. The composition itself happens in one single step via eglSwapBuffers, that is sent via GPU process via its command buffer. Internally (and when using Mesa) the EGL implementation of Wayland checks the need of creating a DRM buffer so the content of the color buffer can be visible on the screen. Nevertheless, this solution comprehends of one single Wayland accelerated window as the "view port" and all the composition happens on top of it. That said, there are definitely room for optimization -- due to be explored.
Under the hood, a couple of changes needed to happen to make it possible. It was built a C++ wrapper support on libwayland client so Chromium code base could access directly it. Thus, a MessagePumpWayland (based on Glib's) was added for iterating Wayland in the message loop of Chromium. Besides the event handler, native event types were also introduced for converting Wayland specific events to Chromium's. Also, a GL (EGL with OpenGLES) implementation Wayland specific was introduced with its native widget types. On Aura framework, a root window desktop host implementation based on Wayland was added and a desktop_aura also for Views widget so aura_demo and content_shell could be ran for demoing purposes. Additionally, ui_unittests and base_unittests are running with successful results.
Everything should be target upstream, within Chromium community; we haven't identified any tasks that the development should not happen there so far. Tasks should be coordinated with Tiago Vignatti a priori.
-
Submit first batch to upstream review:
- https://github.com/tiagovignatti/misc/tree/master/chromium
- Intel's ACL with Tiago as a contributor (DONE by Tiago).
- contact Google lead developers (DONE by Tiago)
- waiting Google's response how to proceed (BLOCKED on Google)
-
port Chrome browser:
- should be fairly straightforward to be honest
- task estimation: 1 or 2 weeks.
-
use command-buffer instead in-process whenever using 3D contexts:
- cross-process image transport should be implemented
- task estimation: 2 weeks.
-
Implement cursor routines for DesktopWindowHostWayland
- cursors changes are not handled at the moment
- task estimation: a few days
-
Use headless Weston for testing units
- just like xvfb is being used now on X11 platform, we'd need a Weston for Wayland.
- task estimation: 1 week.
- native events conversion to Wayland
- most of the code is there already within the first batch of patches, but in practice content_shell is not receiving the native input events properly.
- task estimation: 1 or 2 weeks.
- DONE by Tiago (21 Jun 2013)