Make WebView work for external displays (over Presentations).

ui/android/window_android.h

 // Copyright 2013 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #ifndef UI_ANDROID_WINDOW_ANDROID_H_
 #define UI_ANDROID_WINDOW_ANDROID_H_
 
 #include <jni.h>
 #include <string>
 #include <vector>
 
 #include "base/android/jni_weak_ref.h"
 #include "base/android/scoped_java_ref.h"
 #include "base/observer_list.h"
 #include "base/time/time.h"
 #include "ui/android/ui_android_export.h"
+#include "ui/gfx/android/device_display_info.h"
 #include "ui/gfx/geometry/vector2d_f.h"
 
 namespace ui {
 
 class WindowAndroidCompositor;
 class WindowAndroidObserver;
 
 // Android implementation of the activity window.
 class UI_ANDROID_EXPORT WindowAndroid {
  public:
@@ skipping 35 matching lines @@
                jlong period_micros);
   void Animate(base::TimeTicks begin_frame_time);
   void OnActivityPaused(JNIEnv* env, jobject obj);
   void OnActivityResumed(JNIEnv* env, jobject obj);
 
   // Return whether the specified Android permission is granted.
   bool HasPermission(const std::string& permission);
   // Return whether the specified Android permission can be requested by Chrome.
   bool CanRequestPermission(const std::string& permission);
 
+  const gfx::DeviceDisplayInfo& GetDeviceDisplayInfo();
+  void UpdateDeviceDisplayInfo();
+
+  base::android::ScopedJavaLocalRef<jobject> GetJavaDisplayContext();

[boliu, 2015/07/15 06:38:47]

Looks like this is public only for ResourceManager construction?

Is it possible to hide the java object implementation internal to ui layer, ie
maybe ResourceManager can take a WindowAndroid pointer instead?

[gsennton, 2015/07/15 19:26:21]

That should work, I am not sure how we would handle a potential null ref to the
WindowAndroid Context over in the ResourceManager though (I guess with the code
of this PS we aren't handling a potential null reference either...).

Another problem is that resource_manager_impl_unittest.cc constructs a
ResourceManagerImpl which is easy to do now with
base::android::GetApplicationContext() but it might be difficult to pass a
WindowAndroid java object instead? (I guess we could create some empty
WindowAndroid object where only the Context is important...)

[boliu, 2015/07/16 14:36:56]

ResourceManager is created during construction, while we still haven't given up
the strong reference to the context, right?

Maybe the context should come directly from java ContentViewCore instead then?

Context being null can only happen after java webview has been gc-ed, which
usually is not during construction.

[gsennton, 2015/10/20 13:27:12]

I'm not sure how we would pass it from the ContentViewCore, this is constructed
in compositor_impl_android.cc from where we have access to a NativeWindow. How
would you get the context directly from the ContentViewCore?

Going back to your first suggestion. Could we just have two constructors in the
native ResourceManagerImpl, one of which takes a WindowAndroid and one which
doesn't take anything but instead passes the application context to a special
java-side createForTests method in ResourceManager.java? So that the
create(WindowAndroid, ...) method creates a new ResourceManager through passing
the display context of the WindowAndroid while the createForTests(Context, ...)
simply passes the given (application)context.

I assume that we would make WindowAndroid.getDisplayContext() package private
then, though WindowAndroid resides in org.chromium.ui.base while ResourceManager
resides in org.chromium.ui.resources. Is there some way to make this private to
the whole ui-package rather than only org.chromium.ui.base?

[boliu, 2015/10/20 15:07:22]

Got lost in the pronoun game. What's "it" and "this"?
Nope..

[gsennton, 2015/10/20 18:46:44]

Ah, sorry:

I'm not sure how we would pass it = 'the display Context' from CVC, this = 'the
resource manager' is constructed in compositor_impl_android.cc from where we
have access to a NativeWindow... [and the rest of the comment should be
understandable :)]

[boliu, 2015/10/21 15:54:59]

native WindowAndroid is already passed to CompositorImpl constructor. It's just
typedef-ed to gfx::NativeWindow:

typedef ui::WindowAndroid* NativeWindow;

Yay?

[gsennton, 2015/10/21 16:35:32]

Yes, but the problem is that GetJavaDisplayContext is public and only used from
compositor_impl_android.cc and if we want GetJavaDisplayContext to be private we
can't use it in compositor_impl_android.cc. You suggested instead passing a java
WindowAndroid to ResourceManager and from the ResourceManager fetch the display
context in a way that would be internal to the ui layer. But if we make
WindowAndroid.getDisplayContext() package private we still can't access it from
ResourceManager since WindowAndroid resides in org.chromium.ui.base and
ResourceManager resides in org.chromium.ui.resources.


Anyway, I think it is easier / clearer to continue this discussion over in
https://codereview.chromium.org/1419843002
:)

+
  private:
   ~WindowAndroid();
 
   base::android::ScopedJavaGlobalRef<jobject> java_window_;
   gfx::Vector2dF content_offset_;
   WindowAndroidCompositor* compositor_;
 
   base::ObserverList<WindowAndroidObserver> observer_list_;
+  scoped_ptr<gfx::DeviceDisplayInfo> device_display_info_;
 
   DISALLOW_COPY_AND_ASSIGN(WindowAndroid);
 };
 
 }  // namespace ui
 
 #endif  // UI_ANDROID_WINDOW_ANDROID_H_