Closed Bug 1453367 Opened 2 years ago Closed 11 months ago
Stand up Web
Render on Android/Gecko View
It would be really valuable to see how well it runs there.
Here is a patch with hacks I used to see if WebRender would work. IIRC it didn't crash but also didn't draw anything. Will try to find time to work on it some more, but no promises!
Summary: Standup WebRender on Android → Stand up WebRender on Android
2 years ago
Priority: -- → P1
By following https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Simple_Firefox_for_Android_build carefully, I was able to get an android gecko build with source-level native debugging working. I didn't need to apply the attached patch, but I did run into several issues. I've worked around a couple, but have hit a blocker that will need some help from someone on the Gecko team. To get a build with WR, I did the following: * Hard-coded gfxPlatform::WebRenderEnvvarEnabled() to return true. * Disabled the android-specific code in InitWebRenderConfig() that force disables WR. The first problem I ran into is an assert in CompositorBridgeParent::RecvForceIsFirstPaint() due to mCompositionManager being null. The implementation of this method in CrossProcessCompositorBridgeParent.h is a no-op, so I locally made it a no-op in the android build too. I don't know if this is correct. After that, the code hits an assert MOZ_ASSERT(metadata) in ClipManager::DefineScrollLayers(), where aASR->mScrollableFrame->ComputeScrollMetadata() returns None. Any suggestions on what should be occurring in this code path or why it's different on android compared to desktop?
(In reply to Glenn Watson [:gw] from comment #2) > After that, the code hits an assert MOZ_ASSERT(metadata) in > ClipManager::DefineScrollLayers(), where > aASR->mScrollableFrame->ComputeScrollMetadata() returns None. > > Any suggestions on what should be occurring in this code path or why it's > different on android compared to desktop? This difference might be caused by "containerful root scroll frames". You can simulate this condition on Desktop by setting the pref layout.scroll.root-frame-containers to true.
Yup, I can confirm that I get the same assertion failure on desktop with WR + that pref enabled.
If I set the layout.scroll.root-frame-containers pref to the same value as desktop, and comment out a couple of MOZ_ASSERT(CompositorThreadHolder::IsInCompositorThread()) calls in AndroidDynamicToolbarAnimator, it *almost* seems to be working. The webpage view appears to be all white, however if you use a touch to try and scroll down, the actual content of the webpage is clearly visible where the rubber-band overscroll effect draws. From what I can see of the content in the rubber-band effect, the web page content looks to be correctly drawn. Does anyone have any ideas what may cause such behavior?
(In reply to Glenn Watson [:gw] from comment #5) > From what I can see of the content in the rubber-band effect, the web page > content looks to be correctly drawn. > > Does anyone have any ideas what may cause such behavior? This is likely a result of the no-op'd RecvForceIsFirstPaint thing. The Fennec code has a SurfaceView that it sets a background color before the first paint of a page (either during initial load or after a tab switch). The background color is set to transparent when it gets the first-paint notification, at . Likely that's not getting hit, resulting in the background color remaining non-transparent, obscuring the painted content. For a temporary hack you can change  and  to use Color.TRANSPARENT and see if that gets you any further.  https://searchfox.org/mozilla-central/rev/033d45ca70ff32acf04286244644d19308c359d5/mobile/android/geckoview/src/main/java/org/mozilla/geckoview/GeckoView.java#290  https://searchfox.org/mozilla-central/rev/033d45ca70ff32acf04286244644d19308c359d5/mobile/android/geckoview/src/main/java/org/mozilla/geckoview/GeckoView.java#202  https://searchfox.org/mozilla-central/rev/033d45ca70ff32acf04286244644d19308c359d5/mobile/android/geckoview/src/main/java/org/mozilla/geckoview/GeckoView.java#180
Screenshot of WR running in Gecko on a Nexus 9 tablet.
This is a patch which contains all the local hacks I applied to get WR running on Android in Gecko, in case anyone else wants to experiment locally.
Attachment #8967026 - Attachment is obsolete: true
Nice! It's good to see there's only a few things that really need fixing. I'll file bugs with details.
Depends on: 1479754
Depends on: 1479755
Depends on: 1479757
Assignee: nobody → gwatson
Adjusting title so that this explicitly refers to GeckoView. Firefox for Android (aka Fennec) is in maintenance mode, so there's not much point trying to enable WR there. And GeckoView is e10s-enabled, which will definitely impact the zooming implementation if nothing else. So time spent here is better spent on GeckoView than on Fennec, because work done for Fennec may not be applicable for GeckoView.
Summary: Stand up WebRender on Android → Stand up WebRender on Android/GeckoView
Depends on: 1498699
Depends on: 1485834
Assignee: gwatson → kats
I had to bisect a problem so I created builds based on the last few Android nightly m-c revisions. Putting this here in case anybody needs it later. Note that WR is enabled by default in the GeckoView Example app (the geckoview_example.apk is in the artifacts list of the build job) but not in Fennec itself. https://treeherder.mozilla.org/#/jobs?repo=try&author=kgupta%40mozilla.com&group_state=expanded&fromchange=d5d68cf6e33f568ee806bd1a868188d8587ced57&tochange=53892fbb31ba1fff82fb70a62b0725dd6ee30ca8
Depends on: 1499785
Depends on: 1499789
Now that it no longer crashes on startup, we can allow enabling WR on GeckoView. It's still not trivial at the moment since none of the GeckoView-based products have an about:config, but at least you can set env vars. So for the GeckoView example app, for instance, you can download the .apk from TreeHerder (it's an artifact on the android build job) and install it, and then run like so: adb shell am start -n org.mozilla.geckoview_example/.GeckoViewActivity --es env0 MOZ_WEBRENDER=1 to run with WR enabled. There is also some discussion around publishing a Reference Browser to the Play Store, and adding some settings there to enable WR.
Pushed by email@example.com: https://hg.mozilla.org/integration/autoland/rev/dc03893f95d7 Allow enabling WebRender on non-Fennec Android. r=jnicol
No longer depends on: 1499785
No longer depends on: 1499789
You need to log in before you can comment on or make changes to this bug.