I updated  crbug.com/598880  to try to clarify this. I would like to use the Screen API to fetch display information (which is also what ui::GetScaleFactorForNativeView uses), which means that we need to reach information about the current display through ViewAndroid.

So for any of these call sites to just get the appropriate DPI scale we could just call ui::GetScaleFactorForNativeView(RWHVA.GetNativeView()) since this will tie the DPI fetching to the ViewAndroid API rather than directly to ContentViewCore (and potentially store this value in RWHVA as long as RWHVA can't be updated/reused to target another display).
Currently such a call will just result in fetching the DPI scale for the primary display (but this will change when we change the implementation of ScreenAndroid).

> (and potentially store this value in RWHVA as long as RWHVA can't be updated/reused to target another display).

But what if a view moves from one display to another?

I feel like this is all just current state depending on where the view is currently shown or what it is attached to (also see custom tabs which allow moving to different activities). So better would be to just always dynamically query the view for its *current* window and display/screen.

Sure, dynamically querying the view sounds good to me.

How do custom tabs work, I assume they need to recreate an ActivityWindowAndroid
 when they move to different Activities?

Yes, and then they call ContentViewCoreImpl::UpdateWindowAndroid().

After https://codereview.chromium.org/2122403002/ lands I guess I can remove |ContentViewCore::window_android_| and that can be done through ViewAndroid::GetWindowAndroid() instead.

There are some observer interfaces also so that when the WindowAndroid changes the listeners/observers have to re-register themselves with the new Window. (Maybe that can be simplified a bit when that trickles through ViewAndroid.)

Can I assign this to you to implement GetDisplayNearestWindow() accordingly in screen_android.cc?

It sounds like this is basically what you were doing anyways, looking at https://codereview.chromium.org/1409833004/diff/140001/ui/android/window_android.h which exposes the display info there.

Sure, though these code changes should be possible without a proper implementation of GetDisplayNearestWindow(), right? I.e. just like it is implemented right now - returning GetPrimaryDisplay(). (though the DPI of CVC will then be that of the primary display until we update the implementation of GetDisplayNearestWindow)

The CL you refer to in #6 is old and we are moving towards removing DeviceDisplayInfo instead (see https://docs.google.com/a/google.com/document/d/1fJDGn3wSzKtm7HSkSatWRXgkAZqj95iBJ20gtsZhqrc/edit?usp=sharing).

True, we don't have to change it to move it out of CVC into RWHV.

Besides the implementation behind it (supporting more than the default display), the other thing that we should change is to not cache |dpi_scale_| or anything else in CVC/RWHV (well, or update it when the display changes at least). But your doc seems to address that also: IIUC the caching could be handled inside DisplayHandler, so that we can just always call GetScaleFactorForNativeView(ViewAndroid*) and it would be cheap.

Yepp, the idea would be to cache it in a DisplayHandler. Though, at the moment there is a similar cache available when using DeviceDisplayInfo (only for the primary display) so I'm not sure why we are caching dpi_scale in CVC at all.. will have a look.

Hm, content_view_core_impl.dpi_scale_ was added in
https://chromiumcodereview.appspot.com/11099007
where it was set in the following way:

if (!gfx::Screen::IsDIPEnabled()) {
  dpi_scale_ = 1;
} else {
 scoped_ptr<content::DeviceInfo> device_info(new content::DeviceInfo());
 dpi_scale_ = device_info->GetDPIScale();
}

I think it has just stayed there since then, and that it's not necessary since IsDIPEnabled is no longer used?

A couple of notes here:
1. overscroll_controller_android and popup_touch_handle_drawable also store their own dpi_scale_ variables (rather than storing the content_view_core object itself). Maybe these should hold a reference to a ViewAndroid instead (to be able to change/fetch the dpi_scale dynamically)?
2. Both the OverscrollControllerAndroid::OverscrollControllerAndroid() and PopupTouchHandleDrawable::Create() calls take a ContentViewCore for other reasons than just GetDpiScale - i.e. to initialize the Java side or because ConventViewCoreImpl is an OverscrollRefreshHandler (actually OverscrollControllerAndroid takes a ContentViewCoreImpl while PopupTouchHandleDrawable only takes a ContentViewCore).

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/00aa0b3010a821f1687589ce0d48cf9b81589b50

commit 00aa0b3010a821f1687589ce0d48cf9b81589b50
Author: gsennton <gsennton@chromium.org>
Date: Thu Jul 14 09:32:20 2016

Remove ContentViewCore::GetDpiScale.

This is part of an effort to remove/split up ContentViewCore

BUG= 626788 

Review-Url: https://codereview.chromium.org/2144703003
Cr-Commit-Position: refs/heads/master@{#405456}

[modify] https://crrev.com/00aa0b3010a821f1687589ce0d48cf9b81589b50/content/browser/android/content_view_core_impl.cc
[modify] https://crrev.com/00aa0b3010a821f1687589ce0d48cf9b81589b50/content/browser/android/content_view_core_impl.h
[modify] https://crrev.com/00aa0b3010a821f1687589ce0d48cf9b81589b50/content/browser/android/overscroll_controller_android.cc
[modify] https://crrev.com/00aa0b3010a821f1687589ce0d48cf9b81589b50/content/browser/android/overscroll_controller_android.h
[modify] https://crrev.com/00aa0b3010a821f1687589ce0d48cf9b81589b50/content/browser/android/popup_touch_handle_drawable.cc
[modify] https://crrev.com/00aa0b3010a821f1687589ce0d48cf9b81589b50/content/browser/android/popup_touch_handle_drawable.h
[modify] https://crrev.com/00aa0b3010a821f1687589ce0d48cf9b81589b50/content/browser/renderer_host/render_widget_host_view_android.cc
[modify] https://crrev.com/00aa0b3010a821f1687589ce0d48cf9b81589b50/content/public/browser/android/content_view_core.h