Boot2Servo

• jack: Fabrice, not sure what you wanted to talk about. faramarz said marshall can work on it, too.
• fabrice: Not sure if you need some overview of how b2g works.
• jack: Yes.
• fabrice: It's simple. We use android's basic layers and kernel and a few daemons. Anything you see about Gonk is this small layer that we get from Android. On top of that, we have Gecko. And Gecko has some glue to Gonk, since we have different versions with ICS and newer editions of Android. So the glue changes when those interfaces change. On top of Gonk, we have Gaia that is all the UI on the device. It's all HTML/CSS, including for the Chrome. So Gaia has a special mode for the system app, which provides window management. If you need to display an alert window or other crazy stuff, Gaia has hooks for that. The tricky part of this is that there are some B2G specific Gecko code and some of it is in the Gaia system app. We could not get all the parts of the Gaia embedding into Gaia itself. One important thing in Gaia that we use is special iframes. There is one iframe for the system, and when you open a new window, it's a new iframe. When you open such an iframe (mozbrowser), it gives you special APIs like loadStart, loadEnd, etc.
• dherman: How big is the surface of non-standard additions?
• fabrice: mozbrowser is not too big. In Gaia, it's huge.
• mbrubeck: Hardware, bluetooth...
• fabrice: The telephony parts are crazy.
• pcwalton: I was looking at the parts in Gecko and they're pretty big. Is there any way we can use the telephony stuff? Lots is in dom/ and some is xpcom...
• fabrice: It's pretty tied to Gecko.
• pcwalton: Servo XPCOM bridge?
• kmc: May need a Rust XPCOM bridge anyway for writing Rust components for Gecko.
• pcwalton: Ick.
• fabrice: What are your goals? Running the full stack? If you want to boot up the UI and have the basic iframe mechanisms, that may be more reasonable. We add new APIs all the time. It's a matter of scaling your resources to more people to write more APIs. Also, one thing we have on B2G is that all the content runs out of process. So all the APIs are written to run content out of process and is a bit hard in Gecko.
• jack: Not a problem for us.
• dherman: There are aspects of Servo that should be nice, but the hard question is what should be the route from zero to complete?
• fabrice: What do we want to do? v1 of B2G was two years, not starting from zero.
• dherman: Not starting from zero with servo...
• fabrice: But, Gecko was further than Servo is.
• dherman: I mean that on B2G you have determined many of the issues.
• pcwalton: Idea - how many processes does it use?
• fabrice: One parent and then one process for each app. Can merge processes for low-end devices.
• pcwalton: Content process is sandboxed? So it can't access the baseband. So, if I replace the dialer app content process, what happens?
• fabrice: It goes through the IPC and asks the content process.
• pcwalton: So the dialer app is just a shell, then, remoting the calls to the trusted parent process.
• mccr8: Yes, the child app does not have permissions.
• jack: Suggesting we mimic the IPC protocol and pretend to be Gecko?
• jdm: NOOOOOOuurrrGGGHHH
• pcwalton: Not that. We could jam Servo inside a Gecko content process to do the painting and let Gecko handle the IPC and Gaia/chrome stuff. You might eat a memory cost because you're not sharing data pages anymore, but it might let us avoid writing a telephony stack in Servo.
• zwarich: If we do something like this, there should be a goal that is either some research question we're answering (feasibility); the other is delivering or moving towards delivering some other part of FFOS. This solution seems like it would not be doing either.
• pcwalton: A strategy that might make sense is to show that we can, when running on FFOS hardware, deliver a good experience. Can be done by booting up Gaia. No telephony, fast UI, etc. Once we do that, people will ask, how do we ship it? Then we can talk about it.
• dherman: I agree with both of you. It's not a thing we should invest a zillion resources in. A first proof of concept is important - we need a simple demo (weeks of work, not months of work). A simple demo shows that you can make something real.
• pcwalton: Also lets us test.
• dherman: Focus right now is still on the core of Servo. Shouldn't have three different places where we try to prove we are an improvement.
• jack: We may have the support of Marshall, on Faramarz's team, to help us with this work. The question is: is Servo at a point where he could build the Gaia home screen in Servo?
• pcwalton: We may need some more core web features first.
• jack: I just want to know - what do we need to get Gonk booting to the homescreen and using Servo to paint?
• fabrice: Displaying and getting events needs to be ported to Gonk. Glutin?
• pcwalton: Thinking of providing a CEF C API/ABI with a glutin wrapper - it should be sufficient.
• dherman: Just be because we can't demo end to end doesn't mean we can't make this work start. Who was going to work on this?
• fabrice: Marshall and myself.
• pcwalton: There's some stuff we have to do to prepare for this work - a SM upgrade, some more DOM APIs, etc. I think that it's also valuable to our research goals. Having panning the homescreen and typing working well and scrolling is really important. We already have APZ in Servo, but testing it on FFOS HW is important.
• jack: Two things need to be done. Display/events stuff need to be working on gonk. On device?
• fabrice: Can do on emulator, but it's really slow. If you contact me privately, I might be able to get one for gw.
• jack: Easy enough for us to do that work directly. Second piece was what we need to get the homescreen running. What CSS features are used there? What parts are you two most interested in working on?
• fabrice: I've been looking at getting the gonk toolchain to build Servo. I'm close. It builds, but it doesn't quite link.
• yichoi: Good idea to see the performance of Servo in B2G. There must be questions (like I frequently get) about whether it is even fair, since Gecko has more functionality. It is fair to compare Gecko to the current Servo implementation?
• dherman: It's the first skepticism we get - will we slow down when we implement more of the functionality. I think that means we can't advertise really hard numbers until then, but it doesn't mean we shouldn't start doing this work. I think we're trying to show that it is possible, as opposed to when we can make fair comparisons. In Servo, we've talked about making sure we do web platform features that are likely to cause performance issues. There are many features, like libeditor, that are not central to performance and so should not affect our performance.
• jack: That's why there's weird stuff on our roadmap like flexbox, writing modes, fragmentation, etc. CSS Counters are certainly something we've recently discovered are not great.
• pcwalton: The only way to get there is by implementing more stuff. Given how much we have implemented so far, I am confident that we will keep our performance. Most of the really bad things performance are the older features, not the new things we haven't implemented. We have a lot of the old stuff implemented at this point.
• jack: Sounds like it makes sense to start doing some of this work.
• fabrice: I am also interested in power consumption. We need to improve this a lot. It seems like a huge differentiator for us in our market. That can only be done on-device.
• jack: Our finding on desktop was that we can clock down the cores and run in parallel. Can we do that on devices? We can't test on Android.
• fabrice: yes. On the flame, we can tune the memory, CPU clock, turn off one of the cores, etc.
• jack: Same thing for measuring for FF Android? Dongles? Power seems like a good first benchmark.
• dherman: It feels like a painful choice between browser running faster vs. less power. Pushing it on the user is bad. But, deciding to make your browser slow seems bad. But fast and not differentiating on power is bad... heuristics?
• jack: We may be able to do both with more tuning.
• larsberg: Laleh's patches improve our numbers from the talk.
• dherman: That's good. Not acceptable to have perf parity and better power. Need both. And a terrible product decision...
• fabrice: We can't lose on speed. Not an option.
• dherman: Talking about being slower than our maximum possible performance... maybe it's a product call.
• larsberg: There's a max speed. If you hit 60fps, there is no more gain to be had anyway.
• zwarich: Also the question of how this fits into total system performance. Total CPU layout time is only 20%, not including other stuff running on the system. The power wins from parallel layout may not be the same...
• pcwalton: CSS flow construction and selector matching include? What else is there?
• zwarich: Parsing. Radio.
• jack: Are iframes to different content processes remote?
• fabrice: Yes.
• jack: It sounds like power is the best first goal.
• yichoi: Correctness is also a factor. We might be able to do more or less work to get a mostly correct page layout to reduce power consumption. It's something we've been thinking about.
• larsberg: People have done it with slight blueshift to reduce display usage. If it's not noticable, that makes sense.
• dherman: We would want to make sure the layout is unnoticably different.
• larsberg: I'm a little worried about keeping it building. Please let me know about your build system work.
• jack: Same as Android?
• fabrice: Similar. Not quite identical. There's a huge pile of makefiles you don't want to build. We already build Gecko and SM, so we have support for building whatever we need. We should just use that.
• larsberg: Marshall?
• marshall: I want to sync up with fabrice.
• jack: We just have project hacking time, so you can hang out here (and in #servo). We'll also be here Friday morning. Thursday we are in SF.