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

UI Framework-1: Aura的更多相关文章

  1. Hybrid UI framework shootout: Ionic vs. Famo.us vs. F7 vs. OnsenUI

    1 Introduction In the past 2 years I’ve been working intensively on mobile applications, mostly hybr ...

  2. 00 - Vue3 UI Framework - 阅读辅助列表

    阅读列表 01 - Vue3 UI Framework - 开始 02 - Vue3 UI Framework - 顶部边栏 03 - Vue3 UI Framework - 首页 04 - Vue3 ...

  3. [转]Ionic – Mobile UI Framework for PhoneGap/Cordova Developers

    本文转自:http://devgirl.org/2014/01/20/ionic-mobile-ui-framework-for-phonegapcordova-developers/ Ionic i ...

  4. 05 - Vue3 UI Framework - Button 组件

    官网基本做好了,接下来开始做核心组件 返回阅读列表点击 这里 目录准备 在项目 src 目录下创建 lib 文件夹,用来存放所有的核心组件吧.然后再在 lib 文件夹下创建 Button.vue 文件 ...

  5. 01 - Vue3 UI Framework - 开始

    写在前面 一年多没写过博客了,工作.生活逐渐磨平了棱角. 写代码容易,写博客难,坚持写高水平的技术博客更难. 技术控决定慢慢拾起这份坚持,用作技术学习的阶段性总结. 返回阅读列表点击 这里 开始 大前 ...

  6. 03 - Vue3 UI Framework - 首页

    顶部边栏做完了,接下来开始做官网的首页 返回阅读列表点击 这里 创建视图文件夹 让我们先新建一个 src/views 文件夹,用来存放官网的主要视图 然后在该文件夹下新建两个 vue 文件,作为我们的 ...

  7. 07- Vue3 UI Framework - Switch 组件

    为了更好的提升用户体验,我们这里再做一个很常用的开关组件 switch 返回阅读列表点击 这里 需求分析 开始之前我们先做一个简单的需求分析 switch 组件应分为选中/未被选中,两种状态 可以通过 ...

  8. 08 - Vue3 UI Framework - Input 组件

    接下来再做一个常用的组件 - input 组件 返回阅读列表点击 这里 需求分析 开始之前我们先做一个简单的需求分析 input 组件有两种类型,即 input 和 textarea 类型 当类型为 ...

  9. 09 - Vue3 UI Framework - Table 组件

    接下来做个自定义的表格组件,即 table 组件 返回阅读列表点击 这里 需求分析 开始之前我们先做一个简单的需求分析 基于原生 table 标签的强语义 允许用户自定义表头.表体 可选是否具有边框 ...

  10. 10 - Vue3 UI Framework - Tabs 组件

    标签页是非常常用的组件,接下来我们来制作一个简单的 Tabs 组件 返回阅读列表点击 这里 需求分析 我们先做一个简单的需求分析 可以选择标签页排列的方向 选中的标签页应当有下划线高亮显示 切换选中时 ...

随机推荐

  1. Hibernate 与mybatis的区别

    转自:https://blog.csdn.net/julinfeng/article/details/19821923 为方便以后准备面试,把一些常用的技术整理出来,会不定期更新. 首先简单介绍下两者 ...

  2. 还是bib问题

    虽然昨天把添加bib的基本问题解决了,但是bib的参考文献没有了中括号.查了一下华东师大,只是给出了如何去掉中括号的方法. http://math.ecnu.edu.cn/~latex/doc.htm ...

  3. (转载)ListView与ScrollView冲突的4种解决方案

    问题解决方案1.手动设置ListView高度    经过测试发现,在xml中直接指定ListView的高度,是可以解决这个问题的,但是ListView中的数据是可变的,实际高度还需要实际测量.于是手动 ...

  4. ccs元素分类 gcelaor

    ccs元素的分类与特点 内联元素特点: 1.和其他元素都在一行上: 2.元素的高度.宽度及顶部和底部边距不可设置: 3.元素的宽度就是它包含的文字或图片的宽度,不可改变. inline-block 元 ...

  5. LCT复习

    LCT,虚实链剖分.支持连边和断边操作.Tarjan制造. [HNOI2010]弹飞绵羊 当然这题分块可以做,常数小,但是LCT更无脑. 建立一个虚拟的弹飞节点\(n+1\),初始化时对于一个点假如再 ...

  6. Linux 磁盘管理及分区

    硬盘结构和基础知识  扇区(Sector)为最小的物理储存单位,每个扇区为512 bytes,将扇区组成一个圆就是磁道(track),不同磁盘的相同磁道组成磁柱(Cylinder),磁柱是分区(par ...

  7. 12个Unity5中优化VR 应用的技巧

    本文章由cartzhang编写,转载请注明出处. 所有权利保留. 文章链接:http://blog.csdn.net/cartzhang/article/details/50176429 作者:car ...

  8. HDU 4725 The Shortest Path in Nya Graph

    he Shortest Path in Nya Graph Time Limit: 1000ms Memory Limit: 32768KB This problem will be judged o ...

  9. 安装spark问题汇总

    使用的版本是 spark-1.6.3-bin-without-hadoop 运行spark-shell报错 运行spark-sql报错找不到org.datanucleus.api.jdo.JDOPer ...

  10. 【cocos2d-x 3.7 飞机大战】 决战南海I (二) 我方飞机的实现

    在上一篇中.我们实现了游戏的開始界面,接下来要实现游戏的主界面.主界面包括地图.我方飞机.敌机等 先来实现我方飞机 我方飞机具有哪些属性呢? 飞机要具有生命值.要有动画效果(尾部喷气),飞机不可以飞出 ...