1

Whistler Houdini2

Lars Bergstrom edited this page 2015-06-26 17:28:30 -07:00

Table of Contents

• Agenda
• Layout feature implementation in Houdini
• Sharing DOM feature implementations
• New Houdini specs & feedback
• Servo and Gecko next steps
• Servo security & correctness
• Rust-related features
• Graphics work
• Android WebView implementation
• Telemetry
• Pipelining text shaping

Agenda

• Go over proposed layout-via-Houdini ideas

Layout feature implementation in Houdini

• larsberg: We're interested in ways to implement long-tail web features in JS (partially?). Things like CSS Grid. Would it make sense to implement some things like parser-in-script or layout-in-script?
• roc: I don't think so. Google has done some experiments. They've always ended up gated in performance, memory more than CPU. You can do it, but it's not clear it's going to be a win. You still need to implement the spec, just in JS instead of Rust. If you do the same thing in Rust it's going to be better. Now, you could use the Houdini interfaces internally, whatever they turn out to be. Assuming they survive and end up exposed to the web, writing code to those interfaces internally is nice because it's a stable API that you need anyway. And writing your code validates the interface. But even with that (internal) approach, you may still give up some performance.
• dbaron: Depends what the API is.
• pcwalton: If it's assign-widths, assign-height, etc. it's already close to our internal interface.
• roc: I'm pessimistic about coming up with the ideal interface that will be perfect forever. Houdini will have to provide "good enough" interfaces that we can support forever.
• pcwalton: I can see for something like Grid not having much point to doing it in JS. If JS is easier to write than Rust, we should make Rust better. But what about DOM things like contentEditable?
• roc: That's a good question. Before we go there, consider this: What if we implement Houdini in Gecko, do a Rust implementation of Grid on top of Houdini, and use it in Servo and Gecko? What if we do that for all the other parts of the browser too?
• pcwalton: That would be great.
• roc: We can't do this for everything, because we don't have stable APIs for everything. But we could do it for something like contentEditable.
• pcwalton: We could even share it with Chromium.
• roc: If you do it in JS. I don't think you should, for the same reasons as above. It's an appealing idea to rewrite contentEditable in JS at some stage, but it requires a lot of poorly specced hooks into the engine.
• pcwalton: I talked with Ehsan about this the other day and he said he was okay with either approach. Anyway, I'm glad you bring up the idea of sharing components between Gecko and Servo, because that's seems like the way we're going to end up "shipping" Servo.
• roc: ContentEditable is a very complex feature without a good spec. Features with good specs are much better candidates for rewriting and sharing. If we're going to boil this ocean, we should start with the easy stuff.

Sharing DOM feature implementations

• roc: One thing I'd like is to implement simple standalone DOM APIs, like the DOM Battery API. JS wrappers around system functionality. Why can't we share that? On the Gecko side we need a way to generate WebIDL bindings with Rust implementations.
• pcwalton: We're already using a fork of the binding generator.
• roc: In Gecko, binding implementations need to subclass C++ classes. That needs to be implemented. And you need to do things like call JS functions, be called back from JS. So we need some sort of abstraction layer.
• pcwalton: So we could have the Paris binding generator generate two interfaces to the same implementation. One would handle the Servo hosting side and one to handle the Gecko hosting side, which has the additional subclass, etc. requirements.
• jack: The interface is abstracted already behind code generation.
• roc: Yeah.
• jack: So what we need is generate C++ and C code.
• pcwalton: It probably needs to generate at least a .h file, with nothing but implementations that call C ABI functions.
• jack: We need to generate a C API for the Rust side.
• roc: The Rust code would probably be nicer code, with better ergonomics than our C++ code. And not just because it's better written. One thing we need is a way to integrate the cycle collector.
• pcwalton: We have a compiler plugin that generates GC rooting code, which is all you should need.
• roc: So first thing, we should try to get a very simple component working this way, and then optimize its ergonomics. I don't really know what it would look like to implement Battery API in Rust. We need to make it as nice as possible.
• pcwalton: It's a lot better after our SpiderMonkey upgrade.

New Houdini specs & feedback

• larsberg: They just published a Paint draft yesterday. It looks... like a very early draft.
• dbaron: Feedback from you is important because, architecturally, all the other engines are more similar.
• pcwalton: I'll take a look at the draft.
• jack: The other "specs" are just whiteboard pictures, but SimonSapin [and meeting minutes: https://lists.w3.org/Archives/Public/public-houdini/2015Mar/index.html#msg11 ] can give more information about the discussions that led to them.
• pcwalton: If Houdini's layout APIs do look similar to our internals (which they'd kind of have to to be parallel safe)...
• larsberg: It sounds like they're already talking about something similar
• pcwalton: ...and if Gecko implements those Houdini APIs, then maybe we can start shoving Servo layout code into Gecko.

Servo and Gecko next steps

• jack: What is the timeline or priority for Houdini in Gecko? Will it happen in the next two years?
• roc: I definitely think we need it in the next two years. I plan to tell Chris Beard we need a lot more headcount to work on this problem.
• pcwalton: Houdini? Or shipping Servo code?
• roc: The big problem is, what is the future of browser engines at Mozilla? And I think this is the best plan anyone has come up with. But we can't implement it by telling all the existing Gecko engineers to stop and rewrite everything in Rust. We need to keep doing what we're doing, and also have additional resources working on "oxidation." It's hard to ask for more resources just to do more of the same, but this plan looks like something we can do that's a lot better than what we've been doing.
• jack: Where should those heads sit? And shouldn't some of those be the most experienced people rather than just new browser devs?
• roc: We need more heads to make it happen. But... yes, I think is the answer, if I understood your question. It makes sense for people who know the code to do some rewriting of it.
• jack: It makes sense to have some of the most experienced people working on Servo. I mean, I don't want you to start hacking on Servo in two years and look at the code and say WTF!
• roc: Good point. Anyway, if this is the plan (and it's not clear yet that it is), then before we go hiring a ton of people and writing a ton of code, it's a good time to re-evaluate where we're at with Servo, and make sure there aren't any obvious things we should fix that would affect all the new code we're going to write. If we implement simple DOM APIs, we need to make sure that's as ergonomic as possible before we go and write a lot more of that.
• gw: ??
• pcwalton: We need to go up/down on "magic DOM objects" also.
• roc: Huh?
• pcwaton: This was mwu's idea. Instead of having a Rust struct and a JS reflector, you have a JS object and stuff all the Rust fields into reserved slots. And there's some magic with packing in next/previous pointers.
• roc: This might make sense for Servo but it's not something we want in Gecko. At least initially I'd like to avoid sharing code that touches actual DOM elements, because that gets tricky. But there's a lot of code in Gecko that doesn't. WebAPIs, Web Audio, Media.
• pcwalton: I'm also interested in taking Gecko code and using it in Servo. We already do with Spidermonkey, other libraries.

Servo security & correctness

• roc: Another thing I'd like to be able to do before writing new code is to validate a few of the assumptions we've made. Have you done fuzzing?
• pcwalton: We've fuzzed some parts, like the URL parser and HTML parser. We have not done a lot of fuzzing of layout. I'm sure we'll have a lot of incorrect renderings and panics. I've never seen a security-sensitive segfault in Servo.
• roc: We hope Servo will be more secure; we need to validate that.
• pcwalton: We've seen panics (safe exceptions) but no security-sensitive crashes so far.
• roc: That's great. The more robust you can make that, the better.
• pcwalton: We should turn Jesse's fuzzers loose on Servo.
• dbaron: Those fuzzers can also catch classes of correctness bugs, like making sure that different series of changes that end up in the same state produce the same rendering.
• pcwalton: I'm sure we have some of those bugs.
• larsberg: mbest is very concerned about stability in the graphics stack too.
• roc: That's not something we can always do much about.
• jack: We can make the GPU code run in a separate process.
• roc: Though that doesn't help in cases where we don't crash, but just don't draw anything either.
• jack: Can we have code that tests the pixels on the screen are what we expect?
• roc: Yes, we've experimented with things like that. Though we've even seen crazy bugs where you read back correct data from the GPU but still don't see anything on the screen.

Rust-related features

• roc: There are probably some unexplored ways to leverage having our own compiler and language. One thing that'll be important in the future is doing live updates of running browsers. For security updates. If you keep your browser running for six weeks, there are public security vulnerabilities you are exposed to. If we can do hotpatching...
• pcwalton: LLVM has some support for this.
• jack: With e10s you can even just restart the content process. Could even restart a content process while you're in another tab, and restore the session.
• roc: Live patching is hard, but it's not rocket science. There are a lot of things we like to think about but can't do because of the compiler. So it's interesting in the long term.
• larsberg: If there are things we need from Rust, we should get them on the Rust team's priorities now that they've finished 1.0.
• roc: These things will require more work on Rust and Servo's side, so we need to get more resources there.
• larsberg: We're already driving some Rust changes like XP support, crash reporter support. Getting things prioritized is the important thing.

Graphics work

• pcwalton: We have some graphics work like per-tile display lists we should do before writing too much more code there.
• roc: But the other things we're talking about don't need to block on that.

Android WebView implementation

• roc: I know we've talked about using Servo in Webviews on mobile.
• larsberg: We haven't started wrapping it in a Java API yet. We can wrap it through CEF.
• roc: It would be nice if app developers can use Servo, instead of WebKit (or even Gecko).
• jack: It's fairly feasible, especially if they control the content that gets rendered. They can work around limitations, and we can add features they need.
• roc: It would be really great if you can say, "Actually there are thousands of people using Servo in this partner app."
• pcwalton: I've been working on games and other "app" demos.

Telemetry

• roc: Have you worked on Telemetry?
• pcwalton: Not yet.
• roc: If we're going to go into mobile in a big way, we need telemetry on both mobile and desktop.
• larsberg: It would also tell us how many users we have.
• jack: Who should we talk to about Telemetry?
• roc: bsmedberg. The performance team.

Pipelining text shaping

• pcwalton: The Enlightenment people start preparing fonts and borders as soon as the style system identifies them rather than waiting until painting and got some big wins.
• roc: That sounds promising. I was looking into seeing if we could optimisitically do shaping and fix it up later in Gecko, since it's such an expensive part.
• dbaron: Could you just guess using some conditional info around where the breaks would be?
• roc: We don't shape differently based on breaking in Gecko. We should, but we don't today.
• mbrubeck: BIDI has some different splits, though.
• roc: We don't do that during frame(flow) construction Gecko. BIDI aside, it's easy...
• mbrubeck: There are lots of optimizations on the fast path.
• dbaron: Does BIDI reordering affect shaping?
• roc: I don't think so. Font developers do ask for special effects when there are BIDI changes, but they create circular dependencies between shaping and layout, so we don't implement it (nor does any other browser vendor).