PSA: Aura plans

3,309 views
Skip to first unread message

Carlos Pizano

unread,
Oct 10, 2013, 9:41:01 PM10/10/13
to chromi...@chromium.org
This is an update of our Aura plans first explained in [1] and then in [2]. 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 [3] 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 [4]. 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.

-cpu




Maciej Pawlowski

unread,
Oct 11, 2013, 6:03:24 AM10/11/13
to chromi...@chromium.org
> 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.

Wouldn'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).

> 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.
>
> -cpu

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.

--
BR
Maciej Pawlowski
Opera Desktop Wroclaw

Carlos Pizano

unread,
Oct 11, 2013, 11:16:34 PM10/11/13
to chromi...@chromium.org


On Friday, October 11, 2013 3:03:24 AM UTC-7, Maciej Pawlowski wrote:
> 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.

Wouldn'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).

That is correct. The watchdog eventually will kill the GPU process in many cases.
 

> 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.
>
> -cpu

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.

Great to hear.

Jake

unread,
Oct 12, 2013, 4:10:59 AM10/12/13
to c...@chromium.org, Chromium-dev
Out of curiosity, why are there no plans to move Mac to Aura?


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

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

Sean Watson

unread,
Oct 12, 2013, 3:54:52 PM10/12/13
to chromi...@chromium.org
On Friday, 11 October 2013 09:41:01 UTC+8, Carlos Pizano wrote:
This is an update of our Aura plans first explained in [1] and then in [2]. 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. 

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? 

Tom Wiltzius

unread,
Oct 13, 2013, 6:44:29 PM10/13/13
to c...@chromium.org, Chromium-dev
On Fri, Oct 11, 2013 at 8:16 PM, Carlos Pizano <c...@chromium.org> wrote:


On Friday, October 11, 2013 3:03:24 AM UTC-7, Maciej Pawlowski wrote:
> 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.

Wouldn'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).

That is correct. The watchdog eventually will kill the GPU process in many cases.

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" [1] 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.
 

 

> 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.
>
> -cpu

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.

Great to hear.
 

--
BR
Maciej Pawlowski
Opera Desktop Wroclaw

Tom Wiltzius

unread,
Oct 13, 2013, 6:47:09 PM10/13/13
to nael...@gmail.com, Chromium-dev
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.

Ben Goodger (Google)

unread,
Oct 13, 2013, 11:25:50 PM10/13/13
to Jake H, Carlos Pizano, Chromium-dev
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..

-Ben

Benjamin Staneck

unread,
Oct 15, 2013, 3:03:41 PM10/15/13
to chromi...@chromium.org
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...

Mike Lothian

unread,
Oct 16, 2013, 11:02:01 AM10/16/13
to chromi...@chromium.org
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

Mike

Thiago Farina

unread,
Oct 16, 2013, 12:38:28 PM10/16/13
to mi...@fireburn.co.uk, Chromium-dev
On Wed, Oct 16, 2013 at 12:02 PM, Mike Lothian <mi...@fireburn.co.uk> wrote:
> 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
>
Guys, pardon me, but what Flash, Pepper or whatever has to be with the
Aura plans?

Please, this isn't productive here, if you want to pursue that
discussion, bring it to chromium-discuss group or file a bug in
crbug.com/.

--
Thiago

Benjamin Staneck

unread,
Oct 16, 2013, 12:47:14 PM10/16/13
to chromi...@chromium.org
Because the old Flash does not work in Aura.

John Abd-El-Malek

unread,
Oct 16, 2013, 1:05:41 PM10/16/13
to sta...@gmail.com, chromium-dev
NPAPI plugins including Flash work in Aura. However, per the blog post on NPAPI support in Chromium, that support will be dropped in 2014.


--

Mike Frysinger

unread,
Oct 16, 2013, 1:09:33 PM10/16/13
to Thiago Farina, mi...@fireburn.co.uk, Chromium-dev
On Wed, Oct 16, 2013 at 12:38 PM, Thiago Farina <tfa...@chromium.org> wrote:
> On Wed, Oct 16, 2013 at 12:02 PM, Mike Lothian <mi...@fireburn.co.uk> wrote:
>> 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
>
> Guys, pardon me, but what Flash, Pepper or whatever has to be with the
> Aura plans?

see point 5 in the original e-mail. i'm not saying this sub point is
relevant, but flash behavior is impacted by Aura.
-mike

Stéphane Marchesin

unread,
Oct 16, 2013, 1:20:39 PM10/16/13
to mi...@fireburn.co.uk, chromium-dev
On Wed, Oct 16, 2013 at 8:02 AM, Mike Lothian <mi...@fireburn.co.uk> wrote:
> 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

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.

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

Tom Wiltzius

unread,
Oct 17, 2013, 5:35:14 PM10/17/13
to vap...@chromium.org, Thiago Farina, mi...@fireburn.co.uk, Chromium-dev
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.

Alec Flett

unread,
Oct 17, 2013, 5:59:58 PM10/17/13
to c...@chromium.org, chromium-dev



On Thu, Oct 10, 2013 at 6:41 PM, Carlos Pizano <c...@chromium.org> wrote:

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 [3] 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.

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?

Alec

Carlos Pizano

unread,
Oct 17, 2013, 6:14:32 PM10/17/13
to chromi...@chromium.org, c...@chromium.org
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.
 

Alec

PhistucK

unread,
Oct 17, 2013, 6:18:54 PM10/17/13
to Carlos Pizano-Uribe, Chromium-dev
But you first wrote that Vista also uses the software compositing path. Is that distinct from the Stage3D feature?


PhistucK


--

Tom Wiltzius

unread,
Oct 18, 2013, 10:32:29 AM10/18/13
to Alon Gothshmidt, Carlos Pizano-Uribe, Chromium-dev
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.

cristobal diaz

unread,
Feb 10, 2014, 1:05:54 PM2/10/14
to chromi...@chromium.org
what about of chrome app launcher in linux ??

Thiago Farina

unread,
Feb 10, 2014, 1:12:23 PM2/10/14
to cristoba...@gmail.com, Chromium-dev, Matt Giuca
On Mon, Feb 10, 2014 at 4:05 PM, cristobal diaz <cristoba...@gmail.com> wrote:
what about of chrome app launcher in linux ??

They are working on this. See crbug.com/299250, and probably star it if you want to get notified about the progress on this.

--
Thiago

Matt Giuca

unread,
Feb 10, 2014, 5:53:52 PM2/10/14
to cristoba...@gmail.com, chromium-dev
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.


Matt Giuca

unread,
Feb 10, 2014, 7:09:00 PM2/10/14
to cristobal diaz, chromium-dev
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).

Elliot Glaysher (Chromium)

unread,
Feb 10, 2014, 7:33:33 PM2/10/14
to Matt Giuca, cristobal diaz, chromium-dev
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:
Message has been deleted

shen yi

unread,
Apr 16, 2014, 7:07:00 PM4/16/14
to chromi...@chromium.org
Hi Carlos, is there any plan to move Android Chrome to Aura?

Peter Kasting

unread,
Apr 16, 2014, 7:11:39 PM4/16/14
to sheny...@gmail.com, Chromium-dev
On Wed, Apr 16, 2014 at 4:07 PM, shen yi <sheny...@gmail.com> wrote:
Hi Carlos, is there any plan to move Android Chrome to Aura?

I don't think Aura makes sense for Android, since the Android UI is a separate piece of code written in Java.

PK 

Alexandre Elias

unread,
Apr 16, 2014, 7:12:53 PM4/16/14
to sheny...@gmail.com, Chromium-dev
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.


--
Alex


On Wed, Apr 16, 2014 at 4:07 PM, shen yi <sheny...@gmail.com> wrote:
Hi Carlos, is there any plan to move Android Chrome to Aura?

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

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

shen yi

unread,
Apr 16, 2014, 7:25:16 PM4/16/14
to chromi...@chromium.org, sheny...@gmail.com
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?

Alexandre Elias

unread,
Apr 16, 2014, 7:37:20 PM4/16/14
to sheny...@gmail.com, Chromium-dev
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.

--
Alex

shen yi

unread,
Apr 16, 2014, 7:58:55 PM4/16/14
to chromi...@chromium.org, sheny...@gmail.com
Thanks for the comment, Alex.

Xing

unread,
Feb 24, 2016, 1:54:45 AM2/24/16
to Chromium-dev
Does the Aura Android plans changed?
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写道:

Alexandre Elias

unread,
Feb 24, 2016, 12:45:54 PM2/24/16
to Xing, Chromium-dev
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.


Reply all
Reply to author
Forward
0 new messages