Intent to Implement: mus+ash: separate window manager and other desktop shell features from browser process (ChromeOS)

1023 views
Skip to first unread message

Ben Goodger (Google)

unread,
Nov 23, 2015, 2:24:40 PM11/23/15
to Chromium-dev
mus+ash
(pronounced "mustache")

Contacts

Summary
We're planning to extract window management and other shell functionality from the Chrome browser process. The benefit is performance isolation for system components outside of the browser, and a sharper line between what components are considered part of the ChromeOS UX and what are part of the browser. We are using the external Mojo shell built from mojo/runner and the Mandoline UI Service ("Mus") to facilitate this.

Tactical Details
Mus (pronounced "muse") is a display server built by the Mandoline team, presenting a collection of Mojo interfaces encapsulating rendering, input and windowing. These APIs are mostly asynchronous, which represents a departure from the way Aura event dispatch and handling is performed. As such much of the windowing functionality in src/ash must be re-created with this in mind.

We will be attempting to reuse with minimal changes code that produces the "content" of windows, e.g. anything implemented with Views or Web UI; like Chrome, and various bits of Ash system UI. As such we will be approaching this kind of like a new platform bringup. Where there are classes that end in *Aura, we anticipate adding *Mus equivalents. These changes can be expected up and down the Chrome layercake, including Content (RenderWidgetHostViewMus) and Views (NativeWidgetMus).

Due to the way the Chrome executable and other components are launched from the Mojo shell, it will be possible for us to develop this behind a runtime flag however, unlike other ports (including Aura) that had to rely on build time configuration.

This work will be developed alongside the existing Ash implementation and should have no effect on the existing windowing code. We may refactor some features out of src/ash to be usable by both Ash and mus+ash.

There will be some changes to Content as in the Mus case we are changing the flow of rendering and input, with the browser process and renderers acting as peer clients to Mus, rather than rendering and input flowing through the browser process.

This is only a very high level overview. Please contact me for more details and I can route your query appropriately or stay tuned for focus area design documents.

Code
The core Mojo system can be found in src/mojo
The Mus service is in src/components/mus
The new window manager, and other shell components extracted from Chrome live in src/mash

Bugs

Docs
chromium.org docs link TBD.

-Ben

Dana Jansens

unread,
Nov 23, 2015, 3:03:17 PM11/23/15
to Ben Goodger (Google), Chromium-dev, tdre...@chromium.org, brian...@chromium.org, tan...@chromium.org
On Monday, November 23, 2015, Ben Goodger (Google) <b...@chromium.org> wrote:
mus+ash
(pronounced "mustache")

Contacts

Summary
We're planning to extract window management and other shell functionality from the Chrome browser process. The benefit is performance isolation for system components outside of the browser, and a sharper line between what components are considered part of the ChromeOS UX and what are part of the browser. We are using the external Mojo shell built from mojo/runner and the Mandoline UI Service ("Mus") to facilitate this.

Tactical Details
Mus (pronounced "muse") is a display server built by the Mandoline team, presenting a collection of Mojo interfaces encapsulating rendering, input and windowing. These APIs are mostly asynchronous, which represents a departure from the way Aura event dispatch and handling is performed. As such much of the windowing functionality in src/ash must be re-created with this in mind.

We will be attempting to reuse with minimal changes code that produces the "content" of windows, e.g. anything implemented with Views or Web UI; like Chrome, and various bits of Ash system UI. As such we will be approaching this kind of like a new platform bringup. Where there are classes that end in *Aura, we anticipate adding *Mus equivalents. These changes can be expected up and down the Chrome layercake, including Content (RenderWidgetHostViewMus) and Views (NativeWidgetMus).

Due to the way the Chrome executable and other components are launched from the Mojo shell, it will be possible for us to develop this behind a runtime flag however, unlike other ports (including Aura) that had to rely on build time configuration.

This work will be developed alongside the existing Ash implementation and should have no effect on the existing windowing code. We may refactor some features out of src/ash to be usable by both Ash and mus+ash.

There will be some changes to Content as in the Mus case we are changing the flow of rendering and input, with the browser process and renderers acting as peer clients to Mus, rather than rendering and input flowing through the browser process.

How will this interact with the work being done on unified-begin-frame and input event batching? In particular we're working toward batching input (in the browser process) between frames and driving begin frames in the renderer from the browser, sending all input events just before sending each beginframe signal. 
 

This is only a very high level overview. Please contact me for more details and I can route your query appropriately or stay tuned for focus area design documents.

Code
The core Mojo system can be found in src/mojo
The Mus service is in src/components/mus
The new window manager, and other shell components extracted from Chrome live in src/mash

Bugs

Docs
chromium.org docs link TBD.

-Ben

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

Fady Samuel

unread,
Nov 23, 2015, 3:29:54 PM11/23/15
to Dana Jansens, Ben Goodger (Google), Chromium-dev, tdre...@chromium.org, brian...@chromium.org, tan...@chromium.org
We've been following the unified BeginFrame and input scheduling work and plan to incorporate it into Mus. Mus will issue BeginFrames and input directly to its clients: the window manager, the browser and renderers, etc. This is work in progress.

Fady

---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev+unsubscribe@chromium.org.

Reply all
Reply to author
Forward
0 new messages