Add observers for DIP scale change.

content/public/android/java/src/org/chromium/content/browser/RenderCoordinates.java

Index: content/public/android/java/src/org/chromium/content/browser/RenderCoordinates.java
diff --git a/content/public/android/java/src/org/chromium/content/browser/RenderCoordinates.java b/content/public/android/java/src/org/chromium/content/browser/RenderCoordinates.java
index 5bcebc28c86b732dac67dbb830cd7e9c03ab5c00..ccf8de398471bee13f52ded5dc2676d65cc6cdbb 100644
--- a/content/public/android/java/src/org/chromium/content/browser/RenderCoordinates.java
+++ b/content/public/android/java/src/org/chromium/content/browser/RenderCoordinates.java
@@ -8,7 +8,8 @@ import android.content.Context;
 import android.util.TypedValue;
 
 import org.chromium.base.VisibleForTesting;
-import org.chromium.ui.base.WindowAndroid;
+
+import java.lang.ref.WeakReference;
 
 /**
  * Cached copy of all positions and scales (CSS-to-DIP-to-physical pixels)
@@ -38,7 +39,7 @@ public class RenderCoordinates {
     private float mMaxPageScaleFactor = 1.0f;
 
     // Cached device density.
-    private float mDeviceScaleFactor;
+    private float mDeviceScaleFactor = 1.0f;
 
     // Multiplier that determines how many (device) pixels to scroll per mouse
     // wheel tick. Defaults to the preferred list item height.
@@ -61,14 +62,14 @@ public class RenderCoordinates {
         mContentHeightCss = contentHeightCss;
     }
 
-    void updateDeviceScaleFactorFromWindow(WindowAndroid windowAndroid) {
-        mDeviceScaleFactor = windowAndroid.getDisplay().getDIPScale();
+    void setDeviceScaleFactor(float dipScale, WeakReference<Context> displayContext) {

[Ted C, 2016/10/31 20:02:40]

any reason changes to this file are needed?

I see that onDIPScaleChanged is called on the observer, but would
windowAndroid.getDisplay().getDIPScale(); not be correct at that point?

[Tima Vaisburd, 2016/10/31 20:37:59]

Strictly speaking, this change it not necessary. I think it adds more clarity in
the caller though.
Now ContentViewCore can receive the DIP scale from observer. I wanted to make
the explicit use of it,
so in ContentViewCore we have

void onDIPScaleChanged(float dipScale) {
    mRenderCoordinates.setDeviceScaleFactor(dipScale,
getWindowAndroid().getContext());
    nativeSetDIPScale(mNativeVontentViewCore, dipScale);
}

I think passing just getWindowAndroid() would obscure the fact that we are using
the parameter on the Java side as well.

[Ted C, 2016/11/01 17:07:16]

To continue down this rabbit hole, why does nativeSetDIPScale need
to be called at all?  Why does CVC even keep that value?  Why doesn't
it always pull it from WindowAndroid.

I'd like to get to a place where the value is stored in a single place
instead of having to do keep all of these in sync.

I'm thinking that onDipScaleChanged would just call WasResized and
force that through the normal resize path.
I guess I'm wondering why we need to do the nativeSetDIPScale at all
then.  Why does CVC keep that value instead of pulling it from
WindowAndroid?

I'd rather have WindowAndroid be the only source of truth instead of
trying to keep these in sync.

onDipScaleChanged in that case would just update

[boliu, 2016/11/01 17:13:02]

Reminder WindowAndroid isn't always available, which may or may not cause
problems for this single source of truth plan.

[Tima Vaisburd, 2016/11/01 18:23:26]

My considerations were pretty simple here. Right now dpi_scale() is used in many
places to convert from
pixels to dip on the way from Android API to Chrome. This includes UI gestures
that I think have to be fast. I wanted to eliminate dip scale duplication
between CVC native and Java when I did the first series of refactoring, but
stopped at the current state, thinking that the inlined dpi_scale() was the
necessary cache.

Also, I did not see the good way to pull the info from WindowAndroid before
https://codereview.chromium.org/2416403002/. Even with this CL the connection
between the windowAndroid to its Display is by id, not with direct link.

Would you consider a possibility to address this question in the subsequent CLs?
Please continue your thought.

[Ted C, 2016/11/01 19:04:59]

I think it is fine to do in follow ups, but I would like to know what the
end goal is before we go in too many circles.  But the discussion doesn't
need to be on this change.

Getting back to my original comment about why not passing WindowAndroid,
I think maybe my main issue is that we still need to get the context from
the window android to call this method.  But I think that is actually because
this method is doing things that I don't think belong here.  I find it
unfortunate that we need to do the wheel scroll stuff here.  I think if we
were to store the value as DP then we could calculate it w/o the context.
Or we could pass in the DisplayAndroid (and thus having access to the display
metrics from the display itself instead of the context).

But I guess this is also outside the scope of this change.
I think that's just a copy paste error on my part.

+        mDeviceScaleFactor = dipScale;
 
         // The wheel scroll factor depends on the theme in the context.
         // This code assumes that the theme won't change between this call and
         // getWheelScrollFactor().
 
-        Context context = windowAndroid.getContext().get();
+        Context context = displayContext.get();
         TypedValue outValue = new TypedValue();
         // This is the same attribute used by Android Views to scale wheel
         // event motion into scroll deltas.