+Long in case we need to merge this.

CL: https://chromium-review.googlesource.com/c/590151

I think the right step here would be to investigate why rendering such simple animation is so heavy in Chrome. Adding more components for traction and bumping the priority due to heavy impact on UX.

Stephane, David, any ideas who could have more insight on this? Additional info in b/65065414.

M-61 is already stable.

In OOBE, there is a dialog that says "Checking for updates", and animation in that dialog looks pretty smooth. Is that the paper progress bar, that's expensive?

this animation is based on html element layout change.

So it goes to 3 consumer.

1. html relayout calculation
2. chrome layer update/composition
3. render itself.


I did several tests, including implementing purely native custom bar. So I could eliminate (1) completely.  
Also I tested this on empty system with only one native progress bar alive.
This gives me results.

(2) - takes > 8ms spent on layer system update
(3) - takes > 8ms spent on rendering 19 patches.

Now consider we have target 60fps for smooth things and this means 16ms per frame.
(1) in case of html layout is also >8ms.

As result only this smooth progress bar costs us ~ 1.8 cpu loading.
That mean we take 1.8 cpus out of 4 available and Android booting does not receive these resources.

Back to "Checking for updates"
1. I am not sure how many  layers actually are included in to the update in this case.
2. There are no extensive CPU operations happen behind this progress bar and even spending 1.8 cpu resources may be acceptable.
3. Do we have real numbers for this case? How this animation affects whole system.