Skip to content

Workweek android arm

jdm edited this page Nov 11, 2014 · 1 revision

Servo workweek - Android/ARM

  • jack: What state are we in?
  • larsberg: We need a Rust upgrade, but we need a fix from acrichto first in Rust upstream that fixes getting rlibs linked into the dylibs.
  • jack: Should we start an upgrade for Rust once that lands?
  • larsberg: Yes.
  • jack: What else do we need?
  • larsberg: Strip symbols for use in the ARM emulator.
  • gw: Can we build Android x86 for the x86 emulator?
  • mbrubeck: I think we could.
  • pcwalton: Can we stop creating a new servo process for reftests to speed things up?
  • jack: Could do so.
  • cgaebel: But that might cause some intermittent bugs in our reftests.
  • larsberg: ebalint would like ARM linux (gnueabi), too. Should we add others?
  • jack: Normal Rust, android x86, android arm, and gnu arm?
  • zwarich: Do we need a separate x86 for android or is it normal Rust?
  • larsberg: Does Rust's Android testing infrastructure test in the ARM Android emulator or x86.
  • gw: They must test in the ARM one because it is the only way to test the codegen.
  • larsberg: Makes sense.
  • mbrubeck: Do we have any ARM Linux machines we can use?
  • pcwalton: We should have some for fennec.
  • larsberg: Any specific boards at Szeged?
  • ebalint: Mostly ARM32: Pandaboard and Arndale Exynos Octa 5420 and Odroid XU3 and Chromebook, Juno board (ARM64)
  • jack: I think I have something, too.
  • larsberg: I think they have custom kernels and driver stacks.
  • jack: Mine let me run standard Arch Linux on it.
  • simon: I have a Raspberry Pi.
  • pcwalton: Can we get an ARM 64 machine?
  • larsberg: Might be able to get one from ARM
  • pcwalton: Which processor?
  • zwarich: Must be their only ARM 64-bit processor - they only have one publicly announced.
  • ebalint: We have an ARM 64 board at Szeged as well (the Juno).
  • jack: What will we do on Android for the toolkit?
  • pcwalton: Could call into CEF's C API from JNI. Don't need the CEF headers, but we can just reuse the exported entry points for CEF. Alternatively, we could have a separate port in Servo for the Gecko API.
  • jack: I mean more immediately, mbrubeck has been inverting the message loop.
  • mbrubeck: pcwalton landed that.
  • jack: Won't this break the android port?
  • pcwalton: Probably. Are we gating builds on Android?
  • larsberg: I've been working on the builder, but have a lot of other stuff on my plate right now.
  • pcwalton: I can fix whatever my patch breaks.
  • mbrubeck: Just need to keep the GLUT windowing code to make it work.
  • jack: Other topics?
  • larsberg: I'd like to chat about having a "useable" APK on Android.
  • jack: Who's on it?
  • pcwalton: Which one? Fennec or a little one?
  • jack: Probably inside of Fennec.
  • pcwalton: If we just want a wikipedia browser, don't need much chrome.
  • jack: And if people click it?
  • pcwalton: Back button!
  • mbrubeck: Fennec is maybe not the best way to get there. A minimal URL bar and back/forward would be nice.
  • pcwalton: That is what some of the CEF applications do.
  • jack: I thought the easiest way to get a shell is the Fennec shell?
  • mbrubeck: Yes, for something dogfoodable.
  • pcwalton: What do people want? Just a wikipedia browser?
  • larsberg: I'd like to see something sooner. Maybe just a wikipedia browser that we could give out in an APK soon?
  • pcwalton: Seems reasonable. Could just make Chrome around the CEF framework. Though I don't know how the back button works.
  • jack: New intent?
  • mbrubeck: For a browser, you handle the back button like a key event. You tell the system if you handled it or not.
  • jack: So just have to know when you're at the beginning?
  • mbrubeck: Yes.
  • larsberg: Isn't WebView popular on Android? Should we be exposing that instead of CEF?
  • pcwalton: Harder because requires integrating into a widget framework...
  • mbrubeck: What's the goal for Android? Just a harness for doing experiments? Build a product ourselves (Fennec with Servo engine)? Or a library for Android app developers to embed in their apps? Each have different optimal paths forward.
  • jack: Showing Servo on mobile is where we can show off the most. We want a super-smooth scrolling and interactive features experience that look better in Servo than FF/Chrome on Android.
  • pcwalton: Making a demo - just a minimum amount of chrome.
  • larsberg: I just don't want to block us out from being able to let people push their apps to the play store using WebView on top of Servo.
  • pcwalton: No problems with how we do on that decision.
  • jack: WebView's just a Java API anyway. Need a new name...
  • mbrubeck: Yeah, developers would have to rebuild against Servo.
  • pcwalton: CEF works fine under WebView. Just a question of which set of CEF APIs.
  • mbrubeck: The offscreen CEF APIs are not only harder, but require modifications to get hardware compositing.
  • mbrubeck: So, we want a full-screen Servo app that's useful for a demo and not immediately do the Fennec.
  • jack: Can we search in wikipedia forms yet?
  • jdm: Not yet; rebasing rebasing rebasing.
  • mbrubeck: We could also build some special powers into our iframes to support B2G.
  • pcwalton: Probably not needed for wikipedia. Content can just call back/forward, since we have such minimal chrome.
  • jack: I think there's some security constraint...
  • SimonSapin: Depends if your content can see that it's inside an iframe, as many websites try to break out of that (e.g., to see the URL).
  • jack: For a demo, it doesn't have to be normal UI; we can just implement what we need in the Chrome to make it useful.
  • yichoi: What is the latest status of Aydin's work on the Android APK?
  • larsberg: We are waiting on a Rust fix, but we believe that it should still work. That fix is: https://github.com/rust-lang/rust/pull/18592 . Once it lands, we will perform a Rust upgrade and Android should work.
  • larsberg: We also have an Android buildbot nearly completed for Servo. Once it is online, we will ensure that Android continues to build.
  • jack: Any perf testing on our ARM stuff at all?
  • larsberg: Just laleh, during her internship. My memory is that gw, mbrubeck, and pcwalton landed fixes for what she found and we're within 20% of Firefox on Android for perf-rainbow.html.
  • jack: What are the hotspots? Is there a sampling profiler?
  • pcwalton: I asked jed davis and the short answer is: no. The long answer is that you can build a custom kernel and use some custom drivers and some patches for GCC, then sometimes you can get the perf tool to work.
  • jack: What about on the ARM Linux toolchain?
  • pcwalton: On not a phone? Sure.
  • jack: Like on a pandaboard?
  • pcwalton: Yes, it should be fine. But a lot of the feedback is that it's hard. May require GCC patches. But I think using a custom board is the sanest way. Perhaps oprofile will work?
  • gw: I've used Nvidia's Tegra system profiler before and it looks like it works pretty well.
  • pcwalton: That might be a good way forward.
  • jack: Does anybody have a phone with it?
  • gw: Use a Tegra board. Has to be a newer one, though. Or at least a shield.
  • pcwalton: Can probably order one.
  • gw: The boards are only around $200 or so.
  • larsberg: We can order some boards for people who want to do work on them.
  • jack: These have controllers! So, whomever's building the shell should use this stuff to do basic profiling...
  • jack: Change to Q1 goals? Or push it out?
  • larsberg: I prefer a smaller thing earlier.
  • mbrubeck: A wikipedia-only browser in Q1 seems reasonable. Right now, we have an android thing that uses GLUT. We can GLUT with glutin, and then use the CEF windowed API, and we should be good to go.
  • jack: Move reuse Android chrome to q2 or later?
  • pcwalton: Maybe decide later, based on the feedback to the wikipedia browser.
  • jack: Who owns this?
  • mbrubeck: I can own the wikipedia Android browser.
  • larsberg: I am interested in some of the on-board ARM Linux perf, unless someone else is.
  • kmc: Picking one ARM board for the team to use should simplify things.
Clone this wiki locally