https://www.chromium.org/developers/design-documents/aura-desktop-window-manager

このドキュメントは外観には使えるが古い

プロジェクトの目的

新しいウィンドウマネージャとシェル環境を作る。ハードウェアアクセラレーションを使ったリッチな見栄えで、アニメイテッドなエフェクトのUIを構築する。

制限や目標

• クロスプラットフォーム
• ハードウェアの利用による拡大可能なパフォーマンス
• ChromeとChromeOSの基礎

初期の目標じゃないもの

• マルチモニター
• ソフトウェアレンダリングとリモートデスクトップ
• NPAPIプラグインサポート、これは決して必要ない。Pepperプラグインのみサポートされる。

UIデザイン

Owner: Nicholas Jitkoff (alcor@) (UX) and Kan Liu (kanliu@) (PM)

Chrom UIの簡素な背景説明

WindowsのChromeとChrome OSのUIはsrc/viewsにあるView UI frameworkを使う。ウインドウのコンテントはビューの階層により構築される。ビューのサブクラスはいろいろなコントロールやコンポーネント（ボタンやツールバーなどの）を実装する。いままでは、見栄えをカスタムするためには手作りのコントロールを使っていた（ブラウザのツールバーやタブストリップ）し、OSが提供するコントロールを使っていた。Win32 APIやGtk（Chrome OSの場合）。

ビュー階層はWidgetによってホストされる。Widgetはクロスプラットフォームの型で、プラットフォーム依存のNativeWidgetに依存する。WindowsではNativeWidgetはHWNDをラップし（WindowImpl経由で）Windowsメッセージを処理する。GtkではNativeWidgetGtkがGtkWidgetをラップしシグナルを処理する。

ChromeのUIはもともとWindows用に書かれていた。ビューはもともとプラットフォームニュートラル的だがコードはWin32に深く依存していた。Chromeチームの哲学”完全を善の敵にしない”に従い、短期の成功のための道が選択された。MacとLinuxのChromeはUIに対して別の戦略をとった。積極的にプラットフォームが提供するツールキット（CocoaとGtk）を使った。なのでChrome OSはWin32の影響がifdefによってGtk的に補強された。

プラットフォーム部品に頼ったことでハードウェア加速が利用しづらくなった。ここからAuraが始まった。

プラットフォームネイティブなコントロール（Gtk/HWND）の除去

Owner: Emmanuel Saint-Loubert-Bié (saintlou@) Gtk/HWNDの使用が行き渡っている。それらを除去するためにやるべき仕事は以下のようなもの：

• Options UIからWebUIへの変換。オプションダイアログは多くのGtkを使っている。WebUIに置き換えることでコントロールの数を減らす。
• 他のダイアログのWebUIへの変換。
• Textfiledなどをビューベースで書く。
• AuraベースのRenderWidgetHostViewを書く。

ハードウェア加速によるレンダリング・合成

Owner: Antoine Labour (piman@)

Chromeが始まったときには２つの合成機があった。WebKitで使われたCSS遷移をハードウェア加速させた合成機、ブラウザプロセスのUIスレッドで動くブラウザ合成機（フルスクリーン回転などのビュー変換の実装）。

いろいろな理由により、合成機の統合が望まれた。主要な理由はハードに合わせたパフォーマンスの実現である。それには１つの合成機と描画パスが必要である。ある時点でレイヤツリーの統合も実現したいがこれは大きな問題になることはない。

ブラウザ合成機はui::Compositorの実装により実現している。WebKit-CC合成機を使った実装であるAntoineも進行している。このようにUIは引き続きui::LayerAPIを利用している。述べたようにこれらを１つにする予定である。

合成機は明確に区別されたChromeコードのコンポーネントである。ずっと後になればWebKit合成機はWebKitから抜き出され、WebKitすべてをAuraやViewsで使う必要はなくなる。

Aura WMとシェル

Owner: Ben Goodger (beng@) and Scott Violet (sky@)

Aura

Owner: Ben Goodger (beng@) and Scott Violet (sky@)

大規模なウインドウ変遷を実演するするには、合成機レイヤがWindowsを背負わなければならない、そうすることにより再描画することなくアニメートできる。これを実現するためには単純ウインドウ型を開発し、それはビューのNativeWiget型と互換APIをサポートする必要がある。最初はビューが背負ったビューデスクトップと呼ばれるNativeWidget実装（NativeWidgetViewsと呼ばれる）を試みた。しかしそれでもその階層をホストするためプラットフォーム依存の部品（NativeWidgetWinやNativeWidgetGtk）を必要とした。大きな挑戦の対象はChromeコードに普及しているgfx::NativeView/NativeWindowである。これがGtkWidgetやHWNDを解決するものと期待されている。この考えから''NativeWidgetWin/NativeWidgetGtkが生まれ、ウインドウを適切に扱うための多くの挑戦にさらされている。 いままではコードに対してNativeViewを期待するトップレベルウインドウしか提供しておらずローカライズされたウインドウはなかった。views::ViewはNativeViewになれないためである。このような問題と大きいビュー階層問題がシンプルなaura::Window型へ導いた。aura::Windowは我々がNativeView/NativeWindowと考えるものである（このようにtypedefされている）。ビューシステムに於いて、この型NativeWidgetAuraをターゲットとした新しいNativeWidgetが実装され、GetNativeView()からの戻り値で返られなければならない。aura::Windowは合成機レイヤをラップし、イベント処理やレイヤの描画処理を持つ代表者をもつ。

aura::WindowsはViewsと似ていが単純化されている。aura::Desktop内の１階層である。aura::Desktopはaura::DesktopHostに拘束され、そこにプラットフォーム特有のコードがある。HWNDをラップするDesktopHostもあれば、X windowをラップするそれもある、この考え方からはGtkは存在しない。これはこのように考えられる。つまりプラットフォーム固有のコードはビューから離れ１つのレイヤに押し込められ、画面に描画される。その中に存在するすべてのウインドウは合成している。DesktopHostウインドウは、低レベルのプラットフォームイベントを受け取り、aura::Eventsに変形し、auraウインドウへ送る。auraウインドウは代表者へ送る。ビュー側では、NativeWidgetAuraがaura::Windowの代表者であり、aura::Eventを受け取り（それはプラットフォーム固有イベントとみなされる）、関連するviews::Event型が構築され、組み込まれたビュー階層へ伝達される。Auraはウインドウ階層、イベント変形と伝達にに責任を持ち、フォーカスやアクティブ化の機能に責任を持つ。Auraがビューに利用されるからと言って、ビューそのものを使うものではないことに注意すること。それは玉ねぎの仮想での話で、HWNDやGtkWidgetの用に考えること。

Aura ShellとChromeの統合

Owner: Zelidrag Hornung (zelidrag@) and David Moore (davemoore@) デスクトップ環境は単なるウインドウ型ではない。移動やサイズ変更などのウインドウマネージャ機能を実装した遊び場が必要であっし、画面下部のランチャー機能やステータスエリアであった。これを直接構築するよりも、別コンポーネントとして構築することに決定した。それらはUIコンポーネントやランチャのウインドウ枠から構成されるため、AuraだけでなくViewに依存する必要があるからである。

生産物はaura_shellと呼ばれるシェルライブラリで、Chromeで使えるものである。テスト機能ももちaura_shell.exeと呼ばれる。これはシェルを作成し、いくつかのサンプルウインドウを起動し、機能をテストする。シェル内では、本来ならユーザデータから展開されるモデルは偽装モデルにより提供される。Chromeで実行されたときは本当のデータが提供される。

ChromeOSのUIチームが特にこの機能のために働いている。

実装戦略

複雑なプロジェクトなので、副作用も生じる。作業を分解すると、合成機、Gtk除去、Aura、AuraシェルとChromeの統合になる。

やることが多いので並行して行う。２つの合成機があってはプロジェクトが始まらないので、ウインドウシステムと１つの合成機の作業から始まる。同様に、組み込みビューでの基本シェル動作により、ランチャのようなシェルコンポーネント作業が始まる。同時にウインドウシステムを拡張する。同様に、その背後でApp ListのようなWebUIコンポーネントも始まる。

新しいWidgetシステムの構築なので、新しいターゲットプラットフォームのためのUIと考えるべきである。よってportと考えるべきである。

use_aura=1設定でビルドできる。LinuxとWindowsで動く、このフラグでコンポーネントもビルドされるべきである。