Hi folks,
Sorry this is later than anticipated. I'd like to clarify what's known
about using two GeckoViews in one application.
My understanding to date
========================
* WebApps
N processes, each process has one WebApp activity, each containing 1
GeckoView.
* blassey's launcher [1]
1 process for Fennec and the launcher activity, each containing 1
GeckoView. These two GeckoViews share a single Gecko instance, single
profile, and contend for the message queue. I think this is known, but
blassey didn't seem to think it was a problem for the launcher.
Apps are launched exactly like WebApps, so we have N + 1 + 1 activities,
N + 1 processes, N + 1 + 1 GeckoViews.
Results
=======
Keeping the Search Activity in the same process as Fennec results in
very bad contention. I think this is not feasible -- certainly it
causes major problems -- but I don't understand why it would work for
blassey's launcher and not for the Search Activity. Certainly launching
Fennec from the Search Activity causes lots of trouble locally; I wonder
if blassey's launcher never ran at the same time as Fennec. Comments?
Does anybody have any perspective on how hard it would be to configure
the two GeckoViews to each "own" a separate <browser> in Gecko, and only
render the relevant <browser> in each GeckoView?
Putting the Search Activity in a separate process from Fennec works, *as
long as I change the GeckoView process' profile directory* [2].
Start-up for the GeckoView, and for the launched Fennec, appear to be
equally slow (but I have not measured). I do see evidence of heavy
memory contention, even on my Nexus 5 [3]. For the time being, I think
we can make this option work, and keep finding the dark corners.
Any suggestions, caveats, vision statements, appreciated.
Nick
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1013588
[2] If you see a crash deep in ipc/chromium/..., you may be seeing this.
Make sure your processes are configured to use distinct profiles.
At the moment, I see no GeckoView affordance to set the profile. I'll
add one.
[3] I see Gecko getting onMemoryPressure messages. I also see issues
with, which may be errors in my testing APKs, or may be due to our
surfaces getting destroyed due to memory pressure, or... (These are
speculative interpretations.)
E GeckoGLController(8403) eglCreateWindowSurface threw
E GeckoGLController(8403) java.lang.IllegalArgumentException: Make
sure the SurfaceView or associated SurfaceHolder has a valid Surface
E GeckoGLController(8403) at
com.google.android.gles_jni.EGLImpl._eglCreateWindowSurface(Native Method)
E GeckoGLController(8403) at
com.google.android.gles_jni.EGLImpl.eglCreateWindowSurface(EGLImpl.java:92)
E GeckoGLController(8403) at
org.mozilla.gecko.gfx.GLController.AttemptPreallocateEGLSurfaceForCompositor(GLController.java:296)
E GeckoGLController(8403) at
org.mozilla.gecko.gfx.GLController.updateCompositor(GLController.java:181)
E GeckoGLController(8403) at
org.mozilla.gecko.gfx.GeckoLayerClient$1.run(GeckoLayerClient.java:169)
E GeckoGLController(8403) at
android.os.Handler.handleCallback(Handler.java:730)
E GeckoGLController(8403) at
android.os.Handler.dispatchMessage(Handler.java:92)
E GeckoGLController(8403) at android.os.Looper.loop(Looper.java:137)
E GeckoGLController(8403) at
android.app.ActivityThread.main(ActivityThread.java:5419)
E GeckoGLController(8403) at
java.lang.reflect.Method.invokeNative(Native Method)
E GeckoGLController(8403) at
java.lang.reflect.Method.invoke(Method.java:525)
E GeckoGLController(8403) at
com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1187)
E GeckoGLController(8403) at
com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1003)
E GeckoGLController(8403) at dalvik.system.NativeStart.main(Native
Method)
W GeckoGLController(8403) eglCreateWindowSurface returned no surface!
_______________________________________________
mobile-firefox-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/mobile-firefox-dev
