Aura (obsolete)
This document is still good for a high level overview, with contact information, but many technical details are now obsolete; see the main Aura index for more details.
 

Project Goals

 
The goal is to produce a new desktop window manager and shell environment with modern capabilities. The UI must offer rich visuals, large-scale animated transitions and effects that can be produced only with the assistance of hardware acceleration.
 
Other constraints and goals:
  • Cross platform code, should be able to build and run on Windows (and maybe eventually other platforms), even if we don't have an initial product need for them.
  • Scalable performance characteristics depending on the target hardware capability.
  • Provide the foundation of a flexible windowing system and shell for Chrome and ChromeOS on a variety of form factors.
Notable non-goals for the initial launch of this system include:
  • Multiple monitor support. (This was added later, early 2013)
  • Software rendering mode or any kind of remote desktop capability to the device.
  • NPAPI plugin support. This will never be required. Pepper plugins only will be supported.

UI Design

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

Quick Chrome UI Implementation Backgrounder

 
Chrome UI for Chrome on Windows and Chrome OS is built using the Views UI framework that lives in src/views. The contents of a window is constructed from a hierarchy of views. View subclasses allow for implementation of various controls and components, like buttons and toolbars. Traditionally Chrome has used a mix of hand-rolled controls for aspects of its user interface where a custom look is desired, such as the browser toolbar and tabstrip, and native controls provided by the host platform where a more conventional look is desired, such as in dialog boxes and menus. When run on Windows, the Win32 API provides for native controls in the form of HWNDs, and on ChromeOS, the Gtk toolkit is used to provide native controls.
 
A view hierarchy is hosted within a Widget. A Widget is a cross-platform type, and relies on a NativeWidget implementation that is specific to each host environment to perform some duties. The NativeWidget implementation is actually the connection to the host environment. For example, on Windows a NativeWidgetWin wraps a HWND (via the WindowImpl class), receives Windows messages for event handling, painting, and other tasks. In the Gtk world, a NativeWidgetGtk wraps a GtkWidget and responds to signals. The NativeWidget is responsible for translating platform-specific notifications into cross platform views::Events and other types that the rest of Views code can respond to in a platform-independent fashion.
 
The Chrome UI was originally written for Windows, and so despite the relatively platform-neutral nature of the View hierarchy and much of the views code, Win32-isms did creep in. The philosophy on the Chrome team has always been "let not the perfect be the enemy of the good," so pathways to shorter-term success have been emphasized. The Mac and Desktop-Linux ports of Chrome pursued a different strategy for UI, more aggressively using the native toolkits offered on those platforms (Cocoa and Gtk), so at the start of the Chrome OS project there was still some considerable Win32 influence in Views code. Many of those Win32-isms have been augmented by ifdef'ed Gtkisms.
 
The reliance on platform widget systems has posed a problem though in that it prevents hardware acceleration of elements of the UI and arbitrary transformation of UI controls. The platform native frameworks are also peculiar in a number of ways, sharing constraints that are not relevant to desktop Chrome or Chrome OS. Before long a desire to eradicate our usage of them grew strong enough to begin work on doing so. An effort was spun up spanning several teams to start by removing Gtk usage in the Views frontend code. This has become one of the major sub-projects required for the Aura work described here.
 

Platform Native Control (aka Gtk/HWND) Elimination

 
Owner: Emmanuel Saint-Loubert-Bié (saintlou@)
 
Gtk/HWND use is pervasive. It is used everywhere from the NativeWidget implementations that host the View hierarchy down to individual dialog boxes. Here are examples of work that has been done to eliminate their use:
  • Converted the Options UI to WebUI. The Options dialog boxes were massive platform-native constructs that used many Gtk widgets. Replacing the whole thing with a WebUI implementation has meant many fewer controls.
  • Converted other dialogs to WebUI. In general, if something shows in a tab or in something resembling what could be a window.open() popup (top level window), it is a candidate for conversion to WebUI. While Options was the largest conglomeration of native controls, there is a long tail of other smaller dialogs that contribute to our reliance on Gtk.
  • Written Views-based implementations of some native controls, like Textfield. Some places do not suit conversion to WebUI - e.g. the browser frame window itself. In these cases we have to write new Views-only (often referred to as "pure views" in code) versions of controls like the Textfield.
  • Written Aura-based implementations of the RenderWidgetHostView. Traditionally the RenderWidgetHostView has been a HWND or GtkWidget, and is used as a parent for windowed NPAPI plugins. Since we are only supporting Pepper plugins going forward, we did not need a native window to parent NPAPI plugins and a synthetic implementation could be done.
While many of the major areas have been successfully tackled, this area remains a work in progress.
 

Hardware Accelerated Rendering/Compositor

 
Owner: Antoine Labour (piman@)
 
At the onset of this project Chrome was using two compositors - the compositor used by WebKit to hardware accelerate CSS transitions, and a "Browser Compositor" run in the UI thread of the browser process, used to implement Views transformations like whole-screen rotations.
 
For a number of reasons, it is desirable to unify our compositing efforts here and provide a single compositor. The primary reason is achieving acceptable performance on target hardware. It is necessary to have a single compositor and draw-pass instead of two as we have now. We would also like to unify the layer trees too at some point, although this was deemed less critical.
 
The Browser Compositor is implemented as implementations of a ui::Compositor interface, such as a GL one and a D3D one. Antoine has been proceeding by writing a new implementation that uses the WebKit-CC compositor. This way the UI can continue to use the ui::Layer API as its render target. As mentioned, we may eventually consolidate the API between UI and WebKit.
 
The compositor is a distinct component in Chrome code, consuming only gfx types, WebKit (obviously) and other low level components. In the fullness of time the WebKit compositor will be extracted from WebKit further so that we do not need to drag all of WebKit into Aura and Views.
 

Aura WM and Shell

 
Aura
 
Owner: Ben Goodger (beng@) and Scott Violet (sky@)
 
To allow us to perform large scale window transitions, we need to back Windows by compositor layers so that we can animate them without redrawing. This led to the development of a simple window type that supported an API compatible with (i.e. implementing the other side of the contract expected by) the Views NativeWidget type. We had initially tried to do this with a View-backed NativeWidget implementation (called NativeWidgetViews) called the views-desktop. However we still needed a platform-native widget (NativeWidgetWin/NativeWidgetGtk) to host the hierarchy. A big challenge was that pervasive in Chrome code is the concept of a gfx::NativeView/NativeWindow, which on Chrome OS and Windows was expected to resolve to a GtkWidget or an HWND. This assumption is also baked into NativeWidgetWin/NativeWidgetGtk and thus we were presented with many challenges parenting windows properly, since we could only ever offer the top level (desktop/screen-level window) as a parent to code that expected a NativeView, rather than a more localized (and probably more correct) window, because a views::View couldn't be a NativeView.
 
This, combined with some lingering issues with large View hierarchies led to the development of the simple aura::Window type. The aura::Window is what we consider a NativeView/NativeWindow (it typedefs thus). In the Views system, we have implemented a new NativeWidget targeting this type (NativeWidgetAura) that returns the bound aura::Window from its GetNativeView() method.
 
The aura::Window wraps a Compositor Layer. It also has a delegate which responds to events and paints to its layer.
 
aura::Windows are similar to Views, only simpler, they are a hierarchy that live within an aura::Desktop. The aura::Desktop is bound to an aura::DesktopHost, which is where the real platform-specific code lives. There is a DesktopHost that wraps an HWND and one that wraps an X window. There is no Gtk in this world. You can think of this as us having pushed the platform specific code one layer further away from Views, out to the screen edge (as far as ChromeOS is concerned). All windows within are synthetic. The DesktopHost window receives the low level platform events, cracks them to aura::Events, targets them to aura Windows, which pass them along to their delegates. On the Views side, NativeWidgetAura is a aura::Window delegate, receives the aura::Event (which it considers a platform native event), and constructs relevant views::Event types to propagate into the embedded View hierarchy.
 
Aura is responsible for the Window hierarchy, event cracking and propagation, and other basic window functionality (like focus, activation, etc).
 
Note that despite the fact that Aura is used by Views, it does not actually use Views itself. It is at a lower level of the onion. Think of it like a raw Win32 HWND or GtkWidget.
 

The Aura Shell and Chrome Integration

 
Owner: Zelidrag Hornung (zelidrag@) and David Moore (davemoore@)
 
A desktop environment is much more than just basic window types. We needed a playground to implement the higher level elements of the window manager, such as constraint-based moving and sizing, shell features such as the persistent launcher at the bottom of the screen, status areas, etc. Rather than build this directly into Chrome, which is huge and takes forever to link, we decided to build this as a separate component. Because it consists of UI components like the launcher and custom window frame Views, it would need to depend not just on Aura but also Views.
 
The product is a shell library (called aura_shell) that (eventually) we can use in Chrome when built with We also have a test runner, called aura_shell_exe. This instantiates the shell, and launches a few sample/example windows that allow us to build out and test functionality. Within the shell, models for components that would normally be populated with user data (such as apps in the launcher) come from mocked models. When instantiated in Chrome, the real data is provided.
 
The Chrome OS UI team has traditionally worked on many of these features and people from that team will contribute heavily to this effort.
 

Implementation Strategy

 
Since this is a complex project, there are several sub-efforts. The breakdown above covers the main areas: Compositor, Gtk-removal, Aura and the Aura Shell/Chrome Integration.
 
There is much work to be done, so we're pursuing a lot of it in parallel. While the two-compositor system in place at the start of the project isn't something we can put into production, it has let us start building out the Windowing system while the single compositor work proceeds. Likewise, getting a basic shell up and running with embedded Views widgets allows shell components like the launcher to be started while other elements of the window system are being designed and constructed. Similarly, Web-UI based components like the App List can be built in Chrome behind a flag independent of any of the rest of this work.
 
Since we're offering a new (native) widget system, our approach to implementing this new UI has been to consider it a new target platform for Chrome, and our work can be considered another "port".
 
You can build the code by setting use_aura=1 in your GYP_DEFINES. This should work from Linux or Windows. This switch should define everything else necessary to make the components above work.
 

Major Revision History

 
11/11/2011 - Ben Goodger and James Cook - revisions
10/5/2011 - Ben Goodger - initial revision

Chromium Graphics: Aura的更多相关文章

  1. Chromium Graphics : GPU Accelerated Compositing in Chrome

    GPU Accelerated Compositing in Chrome Tom Wiltzius, Vangelis Kokkevis & the Chrome Graphics team ...

  2. Chromium Graphics: Compositor Thread Architecture

    Compositor Thread Architecture <jamesr, enne, vangelis, nduca> @chromium.org Goals The main re ...

  3. Chromium Graphics: GPUclient的原理和实现分析之间的同步机制-Part II

    摘要:Part I探析GPUclient之间的同步问题,以及Chromium的GL扩展同步点机制的基本原理.本文将源码的角度剖析同步点(SyncPoint)机制的实现方式. 同步点机制的实现主要涉及到 ...

  4. Chromium Graphics Update in 2014(滑动)

    原创文章,转载请注明为链接原始来源对于http://blog.csdn.net/hongbomin/article/details/40897433. 摘要:Chromium图形栈在2014年有多项改 ...

  5. Chromium Graphics: GPUclient的原理和实现分析之间的同步机制-Part I

    摘要:Chromium于GPU多个流程架构的同意GPUclient这将是这次访问的同时GPU维修,和GPUclient这之间可能存在数据依赖性.因此必须提供一个同步机制,以确保GPU订购业务.本文讨论 ...

  6. Chromium Graphics: Graphics and Skia

    Graphics and Skia Chrome uses Skia for nearly all graphics operations, including text rendering. GDI ...

  7. Chromium Graphics: Video Playback and Compositor

    Video Playback and Compositor Authors: jamesr@chromium.org, danakj@chromium.org The Chromium composi ...

  8. Chromium Graphics: Multithreaded Rasterization

    Multithreaded Rasterization @nduca, @enne, @vangelis (and many others) Implementation status: crbug. ...

  9. Chromium Graphics: HW Video Acceleration in Chrom{e,ium}{,OS}

    HW Video Acceleration in Chrom{e,ium}{,OS} Ami Fischman <fischman@chromium.org> Status as of 2 ...

随机推荐

  1. Linux下处理JSON的命令行工具:jq---安装

    转自:https://blog.csdn.net/Sunny_much/article/details/50668871      JSON是前端编程经常用到的格式.Linux下也有处理处理JSON的 ...

  2. vue 父子组件传值以及方法调用,平行组件之间传值以及方法调用大全

    vue项目经常需要组件间的传值以及方法调用,具体场景就不说了,都知道.基本上所有的传值都可以用vuex状态管理来实现,只要在组件内监听vuex就好. vue常用的传值方式以及方法有: 1. 父值传子( ...

  3. 【转】IIS初始化(预加载),解决第一次访问慢,程序池被回收问题

    原地址:http://www.debugrun.com/a/mpyWXwg.html 读在最前面: 1.本文以IIS8,Windows Server 2012R2做为案例 2.IIS8 运行在 Win ...

  4. (转载) Android两个子线程之间通信

    Android两个子线程之间通信 标签: classthreadandroid子线程通信 2015-03-20 17:03 3239人阅读 评论(0) 收藏 举报  分类: 个人杂谈 版权声明:本文为 ...

  5. BAT 解密(四):配置中心、服务中心、异步技术细节

    在系列文章的第二篇文章< BAT解密(二):聊聊业务如何驱动技术发展 >中我们深入分析了互联网业务发展的一个特点:复杂性越来越高.复杂性增加的典型现象就是系统越来越多,当系统的数量增加到一 ...

  6. Linux部署之批量自动安装系统之DHCP篇

    1.         安装:yum install dhcp   2.         Ip配置信息   3.         Dhcp配置文件如下   4.         配置完后检查语法是否错误 ...

  7. express + jqPaginator 分页展示内容

    写在前面的话 分页展示内容也是我们在页面开发中经常会遇到的需求 前端页面利用jqPaginator这个jquery插件来编写 后端利用mysql存储数据 开始敲代码 回顾sql知识 首先让我们回顾一下 ...

  8. 基本数据类型(dict)

    1.定义 dict => {"key":'value',"a":1} 字典是无序的,字典是可变的 字典的键 => 可哈希(不可变),唯一 字典的值 ...

  9. iOS面试总结(待完善)

    闲的没事总结一下面试资料,先列个大纲,然后慢慢填充,一步步完善,反正也不急. 1.基本属性 2.KVC与KVO 3.代理与block 4.多线程:NSThread,GCD,NSOperation 5. ...

  10. root of factory hierarchy

    项目编译错误! project---->clean