Store physical backing size in ViewAndroid

Store physical backing size in ViewAndroid

Stores physical backing size info in ViewAndroid tree nodes.
It rids CVC of methods related to physical backing size,
and help eliminate the access from RWHVA to CVC done against
layering hierarchy.

BUG=626765, 622847
Review-Url: https://codereview.chromium.org/2842693005
Cr-Commit-Position: refs/heads/master@{#471227}
Committed: https://chromium.googlesource.com/chromium/src/+/fb293a5d27d9f233a801653e4983bef0a92e43e9

[Jinsuk Kim, 2017-04-27 00:29:13]

Description was changed from

==========
Store physical backing size in ViewAndroid

Stores physical backing size info in ViewAndroid tree node.
It reduces the access from RWHVA to CVC (also JNI calls).
|has_content_layer_| was added in RWHVA with a view to
eventually replacing in all the possible places the usage
of |content_view_core_|.

BUG=626765
==========

to

==========
Store physical backing size in ViewAndroid

Stores physical backing size info in ViewAndroid tree nodes.
It rids CVC of another method (getPhysicalBackingSize(),
and help eliminate the access from RWHVA to CVC done against
layering hierarchy.

BUG=626765
==========

[Jinsuk Kim, 2017-04-27 05:12:35]

jinsukkim@chromium.org changed reviewers:
+ boliu@chromium.org

[Jinsuk Kim, 2017-04-27 05:12:36]

This has been tried but held off before. I'd like to give it another try - I
think ViewAndroid tree keeping the latest physical backing size has benefits as
written in the bug description.

[Jinsuk Kim, 2017-04-27 06:53:16]

Description was changed from

==========
Store physical backing size in ViewAndroid

Stores physical backing size info in ViewAndroid tree nodes.
It rids CVC of another method (getPhysicalBackingSize(),
and help eliminate the access from RWHVA to CVC done against
layering hierarchy.

BUG=626765
==========

to

==========
Store physical backing size in ViewAndroid

Stores physical backing size info in ViewAndroid tree nodes.
It rids CVC of another method (getPhysicalBackingSize(),
and help eliminate the access from RWHVA to CVC done against
layering hierarchy.

BUG=626765, 622847
==========

[boliu, 2017-04-27 17:16:23]

On 2017/04/27 05:12:36, Jinsuk Kim wrote:
> This has been tried but held off before. I'd like to give it another try - I
> think ViewAndroid tree keeping the latest physical backing size has benefits
as
> written in the bug description.

I still don't understand how to square this in chrome's world where
EventForwarder will eventually be the root of the tree. Is physical backing size
always the same across all tabs in chrome?

Might make more sense to just move the call to native view_android, then
embedder can get it from WebContents::GetNativeView?

[Jinsuk Kim, 2017-04-27 22:12:22]

On 2017/04/27 17:16:23, boliu wrote:
> On 2017/04/27 05:12:36, Jinsuk Kim wrote:
> > This has been tried but held off before. I'd like to give it another try - I
> > think ViewAndroid tree keeping the latest physical backing size has benefits
> as
> > written in the bug description.
> 
> I still don't understand how to square this in chrome's world where
> EventForwarder will eventually be the root of the tree. Is physical backing
size
> always the same across all tabs in chrome?
> 

Physical size (and view size too, I think) is meant for only the 'active'
content which is at foreground. So it should be applied to the corresponding
view android tree only too. This was different from other events in this sense,
which was the reason you didn't like it to be passed to event forwarder, as I
recall.

> Might make more sense to just move the call to native view_android, then
> embedder can get it from WebContents::GetNativeView?

Would you elaborate? Physical backing size is info that is 'provided' by
embedder, I think...?

[boliu, 2017-04-27 22:12:42]

err, just noticed this unsent comment..

https://codereview.chromium.org/2842693005/diff/40001/content/public/android/...
File
content/public/android/java/src/org/chromium/content/browser/ContentViewCore.java
(right):

https://codereview.chromium.org/2842693005/diff/40001/content/public/android/...
content/public/android/java/src/org/chromium/content/browser/ContentViewCore.java:1141:
public void onPhysicalBackingSizeChanged(int width, int height) {
can this be removed as well, have embedder directly call EventForwarder (or
view_android.h, if you take my other advice)

[boliu, 2017-04-27 22:14:35]

On 2017/04/27 22:12:22, Jinsuk Kim wrote:
> On 2017/04/27 17:16:23, boliu wrote:
> > On 2017/04/27 05:12:36, Jinsuk Kim wrote:
> > > This has been tried but held off before. I'd like to give it another try -
I
> > > think ViewAndroid tree keeping the latest physical backing size has
benefits
> > as
> > > written in the bug description.
> > 
> > I still don't understand how to square this in chrome's world where
> > EventForwarder will eventually be the root of the tree. Is physical backing
> size
> > always the same across all tabs in chrome?
> > 
> 
> Physical size (and view size too, I think) is meant for only the 'active'
> content which is at foreground. So it should be applied to the corresponding
> view android tree only too. This was different from other events in this
sense,
> which was the reason you didn't like it to be passed to event forwarder, as I
> recall.

But code should not assume there's only ever one active view. I mean just think
about the contextual search case

> 
> > Might make more sense to just move the call to native view_android, then
> > embedder can get it from WebContents::GetNativeView?
> 
> Would you elaborate? Physical backing size is info that is 'provided' by
> embedder, I think...?

Yeah, so eg native AwContents can do something like
web_contents->GetNativeView()->SetPhysicalBackingSize(w,h)?

[Jinsuk Kim, 2017-04-27 22:30:37]

On 2017/04/27 22:14:35, boliu wrote:
> On 2017/04/27 22:12:22, Jinsuk Kim wrote:
> > On 2017/04/27 17:16:23, boliu wrote:
> > > On 2017/04/27 05:12:36, Jinsuk Kim wrote:
> > > > This has been tried but held off before. I'd like to give it another try
-
> I
> > > > think ViewAndroid tree keeping the latest physical backing size has
> benefits
> > > as
> > > > written in the bug description.
> > > 
> > > I still don't understand how to square this in chrome's world where
> > > EventForwarder will eventually be the root of the tree. Is physical
backing
> > size
> > > always the same across all tabs in chrome?
> > > 
> > 
> > Physical size (and view size too, I think) is meant for only the 'active'
> > content which is at foreground. So it should be applied to the corresponding
> > view android tree only too. This was different from other events in this
> sense,
> > which was the reason you didn't like it to be passed to event forwarder, as
I
> > recall.
> 
> But code should not assume there's only ever one active view. I mean just
think
> about the contextual search case

Yes that's true but even in such case the physical backing size should only
affect the content for the contextual search case which will be located at the
'top' of the tree stack and is regarded as active (in a narrow sense). The VA
for main content will be right below it and won't be affected. That was how the
experiment we did before was designed.

> 
> > 
> > > Might make more sense to just move the call to native view_android, then
> > > embedder can get it from WebContents::GetNativeView?
> > 
> > Would you elaborate? Physical backing size is info that is 'provided' by
> > embedder, I think...?
> 
> Yeah, so eg native AwContents can do something like
> web_contents->GetNativeView()->SetPhysicalBackingSize(w,h)?

Oh so not through event forwarder but directly to ViewAndroid... 

Then through which class does it reach native from Java? AwContents for WebView,
ContentView for the others?

[boliu, 2017-04-27 22:36:53]

boliu@chromium.org changed reviewers:
+ aelias@chromium.org

[boliu, 2017-04-27 22:36:54]

On 2017/04/27 22:30:37, Jinsuk Kim wrote:
> On 2017/04/27 22:14:35, boliu wrote:
> > On 2017/04/27 22:12:22, Jinsuk Kim wrote:
> > > On 2017/04/27 17:16:23, boliu wrote:
> > > > On 2017/04/27 05:12:36, Jinsuk Kim wrote:
> > > > > This has been tried but held off before. I'd like to give it another
try
> -
> > I
> > > > > think ViewAndroid tree keeping the latest physical backing size has
> > benefits
> > > > as
> > > > > written in the bug description.
> > > > 
> > > > I still don't understand how to square this in chrome's world where
> > > > EventForwarder will eventually be the root of the tree. Is physical
> backing
> > > size
> > > > always the same across all tabs in chrome?
> > > > 
> > > 
> > > Physical size (and view size too, I think) is meant for only the 'active'
> > > content which is at foreground. So it should be applied to the
corresponding
> > > view android tree only too. This was different from other events in this
> > sense,
> > > which was the reason you didn't like it to be passed to event forwarder,
as
> I
> > > recall.
> > 
> > But code should not assume there's only ever one active view. I mean just
> think
> > about the contextual search case
> 
> Yes that's true but even in such case the physical backing size should only
> affect the content for the contextual search case which will be located at the
> 'top' of the tree stack and is regarded as active (in a narrow sense). The VA
> for main content will be right below it and won't be affected. That was how
the
> experiment we did before was designed.

But we are not going to build the "active view" concept into the view tree.

> 
> > 
> > > 
> > > > Might make more sense to just move the call to native view_android, then
> > > > embedder can get it from WebContents::GetNativeView?
> > > 
> > > Would you elaborate? Physical backing size is info that is 'provided' by
> > > embedder, I think...?
> > 
> > Yeah, so eg native AwContents can do something like
> > web_contents->GetNativeView()->SetPhysicalBackingSize(w,h)?
> 
> Oh so not through event forwarder but directly to ViewAndroid... 
> 
> Then through which class does it reach native from Java? AwContents for
WebView,
> ContentView for the others?

I think this is a per-view-subtree thing rather than something that's global to
the entire view tree. Maybe should check with +aelias though

I dunno.. ContentView is going to go away too. Whatever thing that directly
manipulates webcontents in chrome?

[Jinsuk Kim, 2017-04-28 07:58:29]

Patchset #4 (id:60001) has been deleted

[Jinsuk Kim, 2017-04-28 11:53:54]

Description was changed from

==========
Store physical backing size in ViewAndroid

Stores physical backing size info in ViewAndroid tree nodes.
It rids CVC of another method (getPhysicalBackingSize(),
and help eliminate the access from RWHVA to CVC done against
layering hierarchy.

BUG=626765, 622847
==========

to

==========
Store physical backing size in ViewAndroid

Stores physical backing size info in ViewAndroid tree nodes.
It rids CVC of methods related to physical backing size,
and help eliminate the access from RWHVA to CVC done against
layering hierarchy.

BUG=626765, 622847
==========

[Jinsuk Kim, 2017-04-28 11:57:10]

jinsukkim@chromium.org changed reviewers:
+ dtrainor@chromium.org

[Jinsuk Kim, 2017-04-28 11:57:11]

dtrainor@chromium.org: Please review changes in chrome/

Reflecting boliu's feedback - embedders are now left to their own device to
route physical backing size change events instead of using EventForwarder that
is used for events to be propagated based on hit testing. PTAL.

[boliu, 2017-04-29 00:18:40]

https://codereview.chromium.org/2842693005/diff/80001/android_webview/java/sr...
File android_webview/java/src/org/chromium/android_webview/AwContents.java
(right):

https://codereview.chromium.org/2842693005/diff/80001/android_webview/java/sr...
android_webview/java/src/org/chromium/android_webview/AwContents.java:3342:
nativeOnPhysicalBackingSizeChanged(mNativeAwContents, w, h);
merge this with nativeOnSizeChanged (move nativeOnSizeChanged up)

https://codereview.chromium.org/2842693005/diff/80001/content/browser/android...
File content/browser/android/content_view_core_impl.cc (right):

https://codereview.chromium.org/2842693005/diff/80001/content/browser/android...
content/browser/android/content_view_core_impl.cc:224:
GetViewAndroid()->UpdateLayerBounds();
SetLayer should just do this automatically

https://codereview.chromium.org/2842693005/diff/80001/content/browser/android...
content/browser/android/content_view_core_impl.cc:1020:
GetViewAndroid()->UpdateLayerBounds();
this intuitively makes no sense, because now that ViewAndroid is holding
physical size, it should know all the places where it's changed, and just update
layer accordingly

so... why is this needed in the original code, maybe it wasn't?

https://codereview.chromium.org/2842693005/diff/80001/ui/android/view_android.cc
File ui/android/view_android.cc (right):

https://codereview.chromium.org/2842693005/diff/80001/ui/android/view_android...
ui/android/view_android.cc:293: if (client_ &&
client_->OnPhysicalBackingSizeChanged())
this makes no sense, why would client ever want to cancel this?

looking at the use cases, looks like returning false in cases where
OnPhysicalBackingSizeChanged currently returns true works just fine?

https://codereview.chromium.org/2842693005/diff/80001/ui/android/view_android.h
File ui/android/view_android.h (right):

https://codereview.chromium.org/2842693005/diff/80001/ui/android/view_android...
ui/android/view_android.h:138: void OnPhysicalBackingSizeChanged(const
gfx::Size& size);
does this need to be public?

[Jinsuk Kim, 2017-04-30 00:23:50]

https://codereview.chromium.org/2842693005/diff/80001/android_webview/java/sr...
File android_webview/java/src/org/chromium/android_webview/AwContents.java
(right):

https://codereview.chromium.org/2842693005/diff/80001/android_webview/java/sr...
android_webview/java/src/org/chromium/android_webview/AwContents.java:3342:
nativeOnPhysicalBackingSizeChanged(mNativeAwContents, w, h);
On 2017/04/29 00:18:40, boliu wrote:
> merge this with nativeOnSizeChanged (move nativeOnSizeChanged up)

Done.

https://codereview.chromium.org/2842693005/diff/80001/content/browser/android...
File content/browser/android/content_view_core_impl.cc (right):

https://codereview.chromium.org/2842693005/diff/80001/content/browser/android...
content/browser/android/content_view_core_impl.cc:224:
GetViewAndroid()->UpdateLayerBounds();
On 2017/04/29 00:18:40, boliu wrote:
> SetLayer should just do this automatically

Done.

https://codereview.chromium.org/2842693005/diff/80001/content/browser/android...
content/browser/android/content_view_core_impl.cc:1020:
GetViewAndroid()->UpdateLayerBounds();
On 2017/04/29 00:18:40, boliu wrote:
> this intuitively makes no sense, because now that ViewAndroid is holding
> physical size, it should know all the places where it's changed, and just
update
> layer accordingly
> 
> so... why is this needed in the original code, maybe it wasn't?

It was added here: https://codereview.chromium.org/264113003 I think it was just
to utilize |WasResized| for setting physical backing size. Now that we always
set the physical size separately with an explicit way, this won't be necessary.
Removed

https://codereview.chromium.org/2842693005/diff/80001/ui/android/view_android.cc
File ui/android/view_android.cc (right):

https://codereview.chromium.org/2842693005/diff/80001/ui/android/view_android...
ui/android/view_android.cc:293: if (client_ &&
client_->OnPhysicalBackingSizeChanged())
On 2017/04/29 00:18:40, boliu wrote:
> this makes no sense, why would client ever want to cancel this?
> 
> looking at the use cases, looks like returning false in cases where
> OnPhysicalBackingSizeChanged currently returns true works just fine?

Can do without bool return type. Changed to void.

https://codereview.chromium.org/2842693005/diff/80001/ui/android/view_android.h
File ui/android/view_android.h (right):

https://codereview.chromium.org/2842693005/diff/80001/ui/android/view_android...
ui/android/view_android.h:138: void OnPhysicalBackingSizeChanged(const
gfx::Size& size);
On 2017/04/29 00:18:40, boliu wrote:
> does this need to be public?

Yes. The other OnXXX calls are from event forwarder which is a friend of this
class.

[Jinsuk Kim, 2017-05-01 02:34:23]

I'm separating physical/view size change handling. Please take another look
after I fix all the tests.

[boliu, 2017-05-01 14:23:19]

looks like there are test failures, but lg2m otherwise

[Khushal, 2017-05-04 00:01:21]

khushalsagar@chromium.org changed reviewers:
+ khushalsagar@chromium.org

[Khushal, 2017-05-04 00:01:22]

https://codereview.chromium.org/2842693005/diff/120001/android_webview/native...
File android_webview/native/aw_contents.h (right):

https://codereview.chromium.org/2842693005/diff/120001/android_webview/native...
android_webview/native/aw_contents.h:144: void OnPhysicalBackingSizeChanged(
Not used anymore?

https://codereview.chromium.org/2842693005/diff/120001/ui/android/view_androi...
File ui/android/view_android.cc (right):

https://codereview.chromium.org/2842693005/diff/120001/ui/android/view_androi...
ui/android/view_android.cc:234: void ViewAndroid::UpdateLayerBounds() {
I think the caller should update the size *if* they want it to match the
physical backing size. None of the views in content need this. CVC needed it
earlier because its layer used to be a drawing solid color layer, to handle the
case where there was no frame from the renderer. Now that is done using LTH bg
color.

https://codereview.chromium.org/2842693005/diff/120001/ui/android/view_androi...
ui/android/view_android.cc:289: void
ViewAndroid::OnPhysicalBackingSizeChanged(const gfx::Size& size) {
Something still needs to poke RWHVA to send the updated size to the renderer.
Earlier CVC::onPhysicalBackingSizeChanged was doing it. Is that somewhere else
in this patch?

[Jinsuk Kim, 2017-05-08 07:40:44]

https://codereview.chromium.org/2842693005/diff/120001/android_webview/native...
File android_webview/native/aw_contents.h (right):

https://codereview.chromium.org/2842693005/diff/120001/android_webview/native...
android_webview/native/aw_contents.h:144: void OnPhysicalBackingSizeChanged(
On 2017/05/04 00:01:22, Khushal wrote:
> Not used anymore?

Removed.

https://codereview.chromium.org/2842693005/diff/120001/ui/android/view_androi...
File ui/android/view_android.cc (right):

https://codereview.chromium.org/2842693005/diff/120001/ui/android/view_androi...
ui/android/view_android.cc:234: void ViewAndroid::UpdateLayerBounds() {
On 2017/05/04 00:01:22, Khushal wrote:
> I think the caller should update the size *if* they want it to match the
> physical backing size. None of the views in content need this. CVC needed it
> earlier because its layer used to be a drawing solid color layer, to handle
the
> case where there was no frame from the renderer. Now that is done using LTH bg
> color.

Sorry I don't get the suggestion made here. Would you elaborate? How do we know
when callers want the two sizes (view & physical backing) to be matched?

https://codereview.chromium.org/2842693005/diff/120001/ui/android/view_androi...
ui/android/view_android.cc:289: void
ViewAndroid::OnPhysicalBackingSizeChanged(const gfx::Size& size) {
On 2017/05/04 00:01:22, Khushal wrote:
> Something still needs to poke RWHVA to send the updated size to the renderer.
> Earlier CVC::onPhysicalBackingSizeChanged was doing it. Is that somewhere else
> in this patch?

It was present in the earlier patches but removed here, and that was the reason
some tests failed. Put it back.

[Khushal, 2017-05-08 17:55:37]

https://codereview.chromium.org/2842693005/diff/120001/ui/android/view_androi...
File ui/android/view_android.cc (right):

https://codereview.chromium.org/2842693005/diff/120001/ui/android/view_androi...
ui/android/view_android.cc:234: void ViewAndroid::UpdateLayerBounds() {
On 2017/05/08 07:40:44, Jinsuk Kim wrote:
> On 2017/05/04 00:01:22, Khushal wrote:
> > I think the caller should update the size *if* they want it to match the
> > physical backing size. None of the views in content need this. CVC needed it
> > earlier because its layer used to be a drawing solid color layer, to handle
> the
> > case where there was no frame from the renderer. Now that is done using LTH
bg
> > color.
> 
> Sorry I don't get the suggestion made here. Would you elaborate? How do we
know
> when callers want the two sizes (view & physical backing) to be matched? 
> 

Sorry, my point was that VA shouldn't need to do this. The caller can do
view_.GetLayer()->SetBounds(view_.GetPhysicalBackingSize()), if they want their
size to match the physical backing size. VAs are going to be used in the UI and
other cases will not necessarily want these 2 sizes to always match.

And I think it should be fine if you don't do this at all for views in content.
The layers there are plain old hierarchy cc::Layers, not necessary to set their
bounds.

[Jinsuk Kim, 2017-05-10 02:34:37]

Patchset #9 (id:180001) has been deleted

[head06902, 2017-05-10 04:42:20]

head06902@gmail.com changed reviewers:
+ head06902@gmail.com

[head06902, 2017-05-10 04:42:22]

lgtm

[head06902, 2017-05-10 04:42:22]

lgtm

lgtm

[Jinsuk Kim, 2017-05-10 04:47:09]

Patchset #10 (id:220001) has been deleted

[Jinsuk Kim, 2017-05-10 04:47:19]

Patchset #9 (id:200001) has been deleted

[Jinsuk Kim, 2017-05-10 06:05:28]

PTAL

https://codereview.chromium.org/2842693005/diff/120001/ui/android/view_androi...
File ui/android/view_android.cc (right):

https://codereview.chromium.org/2842693005/diff/120001/ui/android/view_androi...
ui/android/view_android.cc:234: void ViewAndroid::UpdateLayerBounds() {
On 2017/05/08 17:55:37, Khushal wrote:
> On 2017/05/08 07:40:44, Jinsuk Kim wrote:
> > On 2017/05/04 00:01:22, Khushal wrote:
> > > I think the caller should update the size *if* they want it to match the
> > > physical backing size. None of the views in content need this. CVC needed
it
> > > earlier because its layer used to be a drawing solid color layer, to
handle
> > the
> > > case where there was no frame from the renderer. Now that is done using
LTH
> bg
> > > color.
> > 
> > Sorry I don't get the suggestion made here. Would you elaborate? How do we
> know
> > when callers want the two sizes (view & physical backing) to be matched? 
> > 
> 
> Sorry, my point was that VA shouldn't need to do this. The caller can do
> view_.GetLayer()->SetBounds(view_.GetPhysicalBackingSize()), if they want
their
> size to match the physical backing size. VAs are going to be used in the UI
and
> other cases will not necessarily want these 2 sizes to always match.
> 
> And I think it should be fine if you don't do this at all for views in
content.
> The layers there are plain old hierarchy cc::Layers, not necessary to set
their
> bounds.

Removed |UpdateLayerBounds()|

[boliu, 2017-05-10 17:09:54]

https://codereview.chromium.org/2842693005/diff/250001/content/browser/androi...
File content/browser/android/content_view_core_impl.cc (left):

https://codereview.chromium.org/2842693005/diff/250001/content/browser/androi...
content/browser/android/content_view_core_impl.cc:228:
GetViewAndroid()->GetLayer()->SetBounds(physical_size);
does that mean you need to bring these calls back?

[boliu, 2017-05-10 17:10:26]

boliu@chromium.org changed reviewers:
- head06902@gmail.com

[Khushal, 2017-05-10 18:13:59]

https://codereview.chromium.org/2842693005/diff/250001/content/browser/androi...
File content/browser/android/content_view_core_impl.cc (left):

https://codereview.chromium.org/2842693005/diff/250001/content/browser/androi...
content/browser/android/content_view_core_impl.cc:228:
GetViewAndroid()->GetLayer()->SetBounds(physical_size);
On 2017/05/10 17:09:53, boliu wrote:
> does that mean you need to bring these calls back?

Nope, its not necessary. A layer's bounds need to be updated only if its going
to clip or its a drawing layer.

[boliu, 2017-05-10 18:17:24]

lgtm

[Jinsuk Kim, 2017-05-11 00:26:16]

jinsukkim@chromium.org changed reviewers:
+ mthiesse@chromium.org

[Jinsuk Kim, 2017-05-11 00:26:17]

mthiesse@chromium.org: Please review changes in Please review changes in
chrome/.../vr_shell*

[mthiesse, 2017-05-11 00:42:38]

lgtm

[David Trainor- moved to gerrit, 2017-05-11 20:07:59]

lgtm

lgtm thanks! :)

[Jinsuk Kim, 2017-05-11 23:02:25]

The CQ bit was checked by jinsukkim@chromium.org

[Jinsuk Kim, 2017-05-11 23:02:26]

The patchset sent to the CQ was uploaded after l-g-t-m from head06902@gmail.com
Link to the patchset: https://codereview.chromium.org/2842693005/#ps250001
(title: "no UpdateLayerBounds")

[commit-bot: I haz the power, 2017-05-11 23:03:57]

CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-05-12 03:23:07]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-05-12 03:23:08]

Try jobs failed on following builders:
  linux_android_rel_ng on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)

[Jinsuk Kim, 2017-05-12 03:30:19]

The CQ bit was checked by jinsukkim@chromium.org

[commit-bot: I haz the power, 2017-05-12 03:30:52]

CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-05-12 05:30:47]

CQ is committing da patch.

Bot data: {"patchset_id": 250001, "attempt_start_ts": 1494559819246830,
"parent_rev": "411384cbbbe54a0a7f6e280705512f83c81f6540", "commit_rev":
"fb293a5d27d9f233a801653e4983bef0a92e43e9"}

[commit-bot: I haz the power, 2017-05-12 05:30:57]

Description was changed from

==========
Store physical backing size in ViewAndroid

Stores physical backing size info in ViewAndroid tree nodes.
It rids CVC of methods related to physical backing size,
and help eliminate the access from RWHVA to CVC done against
layering hierarchy.

BUG=626765, 622847
==========

to

==========
Store physical backing size in ViewAndroid

Stores physical backing size info in ViewAndroid tree nodes.
It rids CVC of methods related to physical backing size,
and help eliminate the access from RWHVA to CVC done against
layering hierarchy.

BUG=626765, 622847

Review-Url: https://codereview.chromium.org/2842693005
Cr-Commit-Position: refs/heads/master@{#471227}
Committed:
https://chromium.googlesource.com/chromium/src/+/fb293a5d27d9f233a801653e4983...
==========

[commit-bot: I haz the power, 2017-05-12 05:30:59]

Committed patchset #10 (id:250001) as
https://chromium.googlesource.com/chromium/src/+/fb293a5d27d9f233a801653e4983...