|PSA: Aura plans||Carlos Pizano||10/10/13 6:41 PM|
This is an update of our Aura plans first explained in  and then in . Please read those if you don't know what Aura is.
At that point we didn't have a timeline but now we do. We are trying to ship Aura on Windows in m32. The main issue is performance but we are making fast progress towards parity on that front. As in any release we are metrics driven; if we don't meet the speed, stability, security metrics we simply don't ship.
Aura is a grand unification of our graphics and UI stack that has significant implications. Here are the ones that you want to be aware of:
1- For Win7 and Win8 machines with capable video hardware and relatively new drivers, Aura fully uses the GPU.
This might lead to issues for some users with non standard configurations. We are increasing the test efforts to include varied hardware but we don't expect to catch every bug.
2- For WinXP and Vista users we will always use the software-only path.
A lot of the performance work we are doing is related to make this mode as fast as it is in m31. However, in the short term we expect to use more CPU cycles and more memory than m31. Part of it is just a trade-off between scrolling performance and use of resources. We'll work to refine our stack in upcoming releases so we only pay the price for the things we really care about.
3- We have an automatic mechanism to switch Chrome from the GPU path to software path if we detect trouble.
It is nearly instantaneous in the case where the GPU process crashes. However, if the GPU process hangs it takes longer for Chrome to detect this condition, and of course BSODs are not something that we can prevent in most cases.
4- Opt-in or out.
In the short term users can opt-in or out from GPU acceleration from the settings menu -> system -> Use hardware acceleration. This setting will go away for XP and Vista users
once we switch to use DX11 because that is not available on those releases. We don't have a timeline for that yet.
5- WebGL and Pepper Flash.
If Aura is in software mode (for XP users for example) both WebGL and Pepper flash are also in software mode. This means that Flash's stage 3D  is unavailable. In previous versions of Chrome we could tolerate some parts of the page using hardware acceleration and others not using it but that is not practical with Aura. In the case of Flash the user can switch to NPAPI flash (for now, NPAPI is going away by the end of 2014) or Opt-in into hardware acceleration.
6- Windows 8 mode and Ash.
Ash is the Aura Shell . Which most people know as the ChromeOS windowing environment. Aura implies Ash, so we decided to use Ash as our shell environment for Windows 8 metro mode. We are currently experimenting on how much of the shell we expose in Windows 8 mode, but even if Chrome m32 looks like m31 in metro mode Ash will still be running under the covers.
7- Linux and Mac.
The plan of record is to move Linux Chrome to Aura in m33. There are no plans to move Mac to Aura.
8- Legacy UI/ Graphics stack.
It will be removed from the codebase once there are no clients . If the current plans hold, it means it will be removed before we branch for m34.
|Re: [chromium-dev] PSA: Aura plans||Maciej Pawlowski||10/11/13 3:03 AM|
> 3- We have an automatic mechanism to switch Chrome from the GPU pathWouldn't a hanging GPU program cause the watchdog timer to restart the
driver after 30 seconds or so? From what I remember, on Vista+ Windows
that no longer introduces a BSOD (as was often the case in XP).
On BlinkOn, we talked with Nat Duca about Aura and Opera, we said we
were using the native UI instead. Turns out, we're switching our Windows
version to Aura after all. So this is okay with us.
Opera Desktop Wroclaw
|Re: [chromium-dev] PSA: Aura plans||Carlos Pizano||10/11/13 8:16 PM|
That is correct. The watchdog eventually will kill the GPU process in many cases.
Great to hear.
|Re: [chromium-dev] PSA: Aura plans||Jake||10/12/13 1:10 AM|
Out of curiosity, why are there no plans to move Mac to Aura?
|Re: PSA: Aura plans||Sean Watson||10/12/13 12:54 PM|
On Friday, 11 October 2013 09:41:01 UTC+8, Carlos Pizano wrote:
Vista with Platform Update has DX11 too, so it should be able to use the same as 7's. Or is this because Vista is out of support from MS, and therefor not worth the effort of backporting?
|Re: [chromium-dev] PSA: Aura plans||Tom Wiltzius||10/13/13 3:44 PM|
On Fri, Oct 11, 2013 at 8:16 PM, Carlos Pizano <c...@chromium.org> wrote:
Somewhat subtle distinction here in that it's both possible for Chrome to detect that our GPU process has hung and kill it, switching to software mode, and it's possible for Windows to detect that a shader is running too long or something else is fishy with the state of the GPU (I don't know what their exact heuristics are) and reset the display driver entirely. The later used to result in a BSOD but now just causes a window flash, reset DirectX devices, and a little bubble to the user saying that the display reset.
I believe this so-called "TDR"  is what Maciej is referring to above, but we try to avoid this situation entirely under normal Chrome operation with our own watchdog timer and various verification steps in ANGLE. It's conceivable that e.g. malicious WebGL content could force a TDR, however.
|Re: [chromium-dev] Re: PSA: Aura plans||Tom Wiltzius||10/13/13 3:47 PM|
The latter. Supporting hardware acceleration features on Vista is actually even more difficult than on XP, because the user population is relatively small and there are some strange bugs we've uncovered in our interaction with DWM that we've been unable to get to the bottom of. Given the small user base and the lack of support from Microsoft, it just isn't worth it.
As for Jake's question about the Mac -- one thing at a time :) I anticipate (and this is not an official plan, this is just me speculating) we'll see movement toward some sort of browser compositor on the Mac in the next year or so, but we more than have our hands full with the current state of flux. We are in the short term attempting to move the Mac to the software compositor where hardware acceleration is unavailable, which will bring us closer to being able to delete the legacy software path in Blink.
|Re: [chromium-dev] PSA: Aura plans||Ben Goodger||10/13/13 8:25 PM|
Chrome on Windows already uses a very custom UI making use of very few native controls. Implementing Aura on Windows Chrome involves scraping off the underlying HWND layer and replacing with the Aura layer. It's not too disruptive to Chrome. The biggest challenges the team has faced is forcing the compositor path for all rendering.
On Mac, we use native widgets extensively. A transition there is a lot more complex, just ask Elliot who has been climbing this hill on Linux. We would need to be certain the benefits outweigh the costs. For right now we're focusing on delivering the best possible experience on Windows and Linux. Once we've achieved that we can take a look at further opportunities, but since no one is chomping at the bit to do this work right now, it is a lower priority..
|Re: PSA: Aura plans||Benjamin Staneck||10/15/13 12:03 PM|
It's actually really sad that "old" Flash has to go away when the new Pepper flash is in no way on par with it. You can't even watch a movie full screen on monitor and work on the second. Such basic things...
|Re: PSA: Aura plans||Mike Lothian||10/16/13 8:02 AM|
I have to agree - it's infuriating that there's no VDPAU or VAAPI support in Pepper flash - I'd really expect the former as it was supported in Adobe's 11.2
Hopefully some Haswell ChromeBooks or AMD APU ChromeBooks will speed up the implementation of this
|Re: [chromium-dev] Re: PSA: Aura plans||Thiago Farina||10/16/13 9:38 AM|
On Wed, Oct 16, 2013 at 12:02 PM, Mike Lothian <mi...@fireburn.co.uk> wrote:Guys, pardon me, but what Flash, Pepper or whatever has to be with the
Please, this isn't productive here, if you want to pursue that
discussion, bring it to chromium-discuss group or file a bug in
|Re: [chromium-dev] Re: PSA: Aura plans||Benjamin Staneck||10/16/13 9:47 AM|
Because the old Flash does not work in Aura.
|Re: [chromium-dev] Re: PSA: Aura plans||John Abd-El-Malek||10/16/13 10:05 AM|
NPAPI plugins including Flash work in Aura. However, per the blog post on NPAPI support in Chromium, that support will be dropped in 2014.
|Re: [chromium-dev] Re: PSA: Aura plans||Mike Frysinger||10/16/13 10:09 AM|
On Wed, Oct 16, 2013 at 12:38 PM, Thiago Farina <tfa...@chromium.org> wrote:see point 5 in the original e-mail. i'm not saying this sub point is
relevant, but flash behavior is impacted by Aura.
|Re: [chromium-dev] Re: PSA: Aura plans||Stéphane||10/16/13 10:20 AM|
On Wed, Oct 16, 2013 at 8:02 AM, Mike Lothian <mi...@fireburn.co.uk> wrote:We already have VAAPI (and V4L2) video decode support on Intel (and
ARM) Chromebooks. It's not supported outside of Chrome OS, but you
might be able to make a one-off build.
|Re: [chromium-dev] Re: PSA: Aura plans||Tom Wiltzius||10/17/13 2:35 PM|
I think there's some confusion about the way Aura impacts Flash. There are two cases:
NPAPI Flash, which will be entirely unaffected by Aura but will stop working when we begin blocking NPAPI plugins (which is a policy change entirely unrelated to Aura).
PPAPI Flash, which will be affected only in that Flash will no longer have access to hardware acceleration features when the rest of Chrome doesn't (i.e. it's blacklisted). In practice this really only impacts Stage3D on Windows XP, where we're broadly permitting Stage3D now but no longer will because the whole browser will be rendered in software mode. There will be no practical impact to Windows 7+, where we only blacklist Flash when we currently blacklist all other GPU features anyway (i.e. because the driver has been demonstrated to be unstable / unreliable). There will also be no practical impact to Flash hardware video acceleration on XP, which has never been supported.
|Re: [chromium-dev] PSA: Aura plans||Alec Flett||10/17/13 2:59 PM|
If you google for "chrome pepper flash" or even just "chrome flash video problems" all you get are resources about how to disable pepper flash and/or switch to NPAPI. Publisher's knee-jerk reaction to flash problems on chrome is to tell people to turn off pepper flash, often because they're using some 3rd party flash video player to show content. Are you concerned that the switch to aura, which will effectively disable stage3d, will further encourage people to turn off pepper flash, making the NPAPI sunset harder?
|Re: [chromium-dev] PSA: Aura plans||Carlos Pizano||10/17/13 3:14 PM|
The switch to Aura will not effectively disable stage3d. For most users, i.e the ones in Win7, Win8, Vista will have the same stage3d experience as before. Like I said, XP users can opt-in if they are willing to take the risk.
NPAPI sunset is mostly a matter of the web platform providing alternatives and content/apps makers taking advantage of them.
|Re: [chromium-dev] PSA: Aura plans||PhistucK||10/17/13 3:18 PM|
But you first wrote that Vista also uses the software compositing path. Is that distinct from the Stage3D feature?
|Re: [chromium-dev] PSA: Aura plans||Tom Wiltzius||10/18/13 7:32 AM|
That's correct, we're lumping Vista into the same configuration bucket as XP for the reasons I cited above. So, yes, both Vista and XP users will lose hardware-accelerated Stage3D support (however, Stage3D will still work, it'll just use a software fallback, i.e. it will be slower).
As I wrote above, Win7+ will be unaffected, so per Alec's question it won't make the NPAPI sunset dramatically harder there. It possibly may on XP and Vista, but frankly our stats don't show that Stage3D usage is so high that I think this will materially impact NPAPI planning.
|Re: PSA: Aura plans||cristobal diaz||2/10/14 10:05 AM|
what about of chrome app launcher in linux ??
|Re: [chromium-dev] Re: PSA: Aura plans||Thiago Farina||2/10/14 10:12 AM|
|Re: [chromium-dev] Re: PSA: Aura plans||Matt Giuca||2/10/14 2:53 PM|
Cristobal: Chrome App Launcher is available in Linux behind a flag.
Just turn on chrome://flags/#enable-app-list (on Dev channel or tip of tree) and you should have an App Launcher shortcut installed in your system menu or applications search (which you can then pin). If you have issues, please comment on http://crbug.com/299250.
|Re: [chromium-dev] Re: PSA: Aura plans||Matt Giuca||2/10/14 4:09 PM|
Sorry, I've just noticed that the latest Dev build (34.0.1825.4) is non-Aura. Was this done for administrative reasons (preparing to launch M34 as GTK)? Or was there another technical issue found?
Anyway, the app launcher only works in Aura, so its availability in Dev depends on it being an Aura build (blue 'a' on the hotdog menu).
|Re: [chromium-dev] Re: PSA: Aura plans||Elliot Glaysher||2/10/14 4:33 PM|
Trunk still has use_aura=1 enabled, but next couple of dev channels will have use_aura=0 in preparation to ship an M34 GTK builds to the beta channel, as which point aura will return on the dev channel.
(Tangentially discussed here:
|Morris Spick||4/15/14 6:45 AM||<This message has been deleted.>|
|Re: PSA: Aura plans||shen yi||4/16/14 4:07 PM|
Hi Carlos, is there any plan to move Android Chrome to Aura?
|Re: [chromium-dev] Re: PSA: Aura plans||Peter Kasting||4/16/14 4:11 PM|
On Wed, Apr 16, 2014 at 4:07 PM, shen yi <sheny...@gmail.com> wrote:
I don't think Aura makes sense for Android, since the Android UI is a separate piece of code written in Java.
|Re: [chromium-dev] Re: PSA: Aura plans||Alexandre Elias||4/16/14 4:12 PM|
We have no major plans there. Android Chrome already shares a common graphics architecture with Aura (delegated rendering). The other parts of Aura that aren't used on Android are mostly desktop-specific UI widgets and windowing functionality. So Android Chrome is largely as Aura-fied as it makes sense to be given its UI. There are a couple of small areas where we could share more code, for example there is some duplication in render_widget_host_view classes, but nothing significant.
On Wed, Apr 16, 2014 at 4:07 PM, shen yi <sheny...@gmail.com> wrote:
|Re: [chromium-dev] Re: PSA: Aura plans||shen yi||4/16/14 4:25 PM|
Thank you, PK & Alex.
I also heard Android may drop SurfaceFlinger and move to other surface composer function, is that true? If yes, how it will affect Android Chrome?
|Re: [chromium-dev] Re: PSA: Aura plans||Alexandre Elias||4/16/14 4:37 PM|
I can't comment on any future Android changes. But, since Chrome just blasts all its GL to one single surface and sometimes overlays a few other Views on top of that, it wouldn't be disrupted by any changes along those lines. Delegated rendering requires only the most baseline surface support from the platform.
|Re: [chromium-dev] Re: PSA: Aura plans||shen yi||4/16/14 4:58 PM|
Thanks for the comment, Alex.
|Re: PSA: Aura plans||2/23/16 10:54 PM|
Does the Aura Android plans changed?
I saw this commit https://codereview.chromium.org/1410153003.
But this commit was reverted soon: https://codereview.chromium.org/1560503002/
Also, there is one issue Issue 551142 said: "Upstream ui_aura for Android Aura"
在 2013年10月11日星期五 UTC+8上午9:41:01，Carlos Pizano写道：
|Re: [chromium-dev] Re: PSA: Aura plans||Alexandre||2/24/16 9:45 AM|
Right, as you can see from the history on the tracking bug http://crbug.com/507792, we recently had a experimental project to make Aura work on Chrome for Android, but we abandoned it before it got too far. We decided that in the context of Android, the cost/benefit of that disruptive architectural shift is not good enough -- particularly since Aura doesn't resemble our phone UI at all -- and we're better focusing our refactoring efforts on other areas instead.
In general, because of the platform UI differences, both Android and Mac don't plan to adopt Aura wholesale, although we do want to continue to converge piecemeal with individual parts of Aura wherever that makes sense.