Meeting 2014 03 10

Agenda

• Parsing & document loading
  • Should we move up history? jgraham says it's tied to document loading
• Embedding progress - zmike
• Convert layout code to use logical directions (prepare for Writing Modes)
• acid2 burndown
• rust upgrade status

Attending

• kmc, larsberg, jdm, jack, zmike, ms2ger, jgraham, simonsapin, pcwalton, brson, dherman, azita

Parsing

• kmc: Starting work on the HTML parser. Tied into that is document lifecycle & script scheduling. We've already talked about most of it on the mailing list. Can we talk about history?
• jdm: Session history & document loading go hand in hand. I have a prototype in my window-proxy PR, which implements a browser context concept. It also involves session history. Also tied up in our existing session history, which revolves around layout instead of DOM things. Page & PageTree implementation there. These are concepts that bholley knows about and has ideas about. Boris, too. Rope them in.
• kmc: Will do. Window proxy relates to when you navigate, there's one that stays the same and one that doesn't?
• jdm: Either that or the Window object will always work on the currently-active window. I think that's the behavior you want.
• kmc: I will follow up offline about what I should be reading about this stuff.
• jdm: jgraham anything to add?
• jgraham: If you want to see the special cases, there are some on document.open. which gives you a completely different Window kind-of, sort-of, ish. I guess by looking at the spec (there is one for it now) you can see how it's supposed to work. Definitely talk to bobby and boris.
• simonsapin: Which spec?
• jgraham: HTML. All is specified in the HTML spec, even though it's not HTML-specific. Artifact of specification history.
• kmc: jdm, when you talk about the existing session history, that's the constellation and its pipelines?
• jdm: Yes, we have the history of pipelines and a bf-cache.
• kmc: Part of the way we want it to work is to keep the pipeline around so that when you go back, the page is right there.
• jdm: Yes, for some subset of history.
• jack: Currently, that's ALL.
• kmc: Definitely observable, since it preserves the state if it's in the cache but a fresh reload if not. That's considered a safe observable difference?
• jdm: Yes, AFAIK.
• jack: How is history related to document loading?
• jdm: Certain loads are replace loads. So, replace the current session history with the current page. Some create a new one. There are rules about all these things.
• jack: Similar to hash url goes to new page but no back entry?
• jdm: Yes. And pushstate and popstate, which do in some cases, but...
• jgraham: Other special cases, like document.write or document.open before the page is finished loading, which doesn't preserve the old session history because the previous page never loaded completely.
• jack: Cases around iframes specified?
• jgraham: I think so. For years it was not completed, but there's been a lot of feedback and it got better. Nobody has done a complete from-scratch impl based on the spec, so there are probably some wrong or missing cases in the spec. There are traps that we will probably fall into.
• simonsapin: When we find those, we should report that to the relevant standards bodies.
• jgraham: For this stuff, there exist some test cases. But because nobody has ever finished writing a from-scratch implementation, there is not a test suite that you could hope covers the test cases.
• jack: So we should be creating that suite?
• jgraham: Yes, when we find edge cases, we should create tests and submit them back to the w3c platform tests
• kmc: So, this project is also validating the existing specs?
• jack: We do all the things!

embedding progress

• zmike: Not a huge amount to report, but if you checked out the ticket, there is a screenshot http://imgur.com/FlAeMVS of Servo hijacking Chromium's CEFSimple thing. It's basically just parsing the arguments and then launching Servo from things that have been provided. It's not rendering into the GTK window. I'm in the middle of the C++ to C conversion, but I'm making some progress there (though it's pretty nightmarish).
• jack: what are you converting from C++ to C?
• zmike: CEF has a C and C++ APIs. The CEFSimple is in C++. The way the C API is written is the C++ calls are shimmed by the C code. I'm trying to figure out where the C functions come into play and to call them in the same place.
• jack: Cool! So this screenshot is actually CEFSimple?
• zmike: Yes, it's CEFSimple launching with my work in progress on the embedding crate instead of running with the Blink engine.
• jack: Are there back buttons and stuff in CEFSimple?
• zmike: No? The CEFSimple is just a servo demo, just launching the webpage and that's it.
• jack: Do they have something similar to MiniBrowser with navigation?
• zmike: Might be CEFClient. I haven't looked at the other ones or the other demos. Even CEFSimple is a beast on its own and it's only 100 lines...
• jack: I'm guessing the other applications are also C++ and that's not super-helpful?
• zmike: I haven't looked into it yet. It's a bit odd because from the tree structure, only the C API is distributed, but there's a clear C++ API...
• kmc: If we decide the C++ API is what we really want to be binding to, should we work on some Rust C++ binding tools? We need to solve it for SpiderMonkey anyway.
• jack: My understanding was that unless the C++ API was very restrictive, we can't use it from Rust.
• kmc: Maybe some Rust community people would help with? Probably would have to use libclang as a library to parse it and emit those shims, etc. It's something other people in the Rust community want, too, so we could get them onboard.
• zmike: Probably not required for CEF, but to be honest I don't know enough C++ for that.
• pcwalton: Getting CEF hooked up to Servo is hard enough. C++ bindings for Servo would make that even tougher right now.

writing modes

• SimonSapin: As you know, I'm joining officially at the end of the month and will be full-time on Servo. I chatted with Jack last week while he was in London, and we talked about doing writing directions as soon as possible. Next week I will be at the Gecko layout workweek in Taipei and I will talk to Simon Montagu about how we should organize the APIs and that kind of stuff. I don't think there is more to discuss right now, I just wanted to bring this up.
• larsberg: How did the suggestion on inline
• SimonSapin: It's about changing the names of the directions from lmeasure and extent... I got good feedback, but I'll mention it in the next working group meeting.
• jack: Let's not land this until after the Rust upgrade, because it will make everybody rebase their PRs.

ACID2 burndown

• jack: We have until the last Friday of this month for Samsung's ACID2 demo. For everyone who's not working on something else, helping to conquer the ACID2 bugs would be great. We have the major features in, but there are probably lots of minor things.
• pcwalton: Status of tables?
• jack: Primary review is done. Needs some refactorings. They fixed all the other issues except the refactoring. I will talk to them tonight or Wednesday.
• pcwalton: Yes, that was 2 weeks ago...
• jack: I get a new batch every 3-4 days, but each says "does not include the refactoring," though I might have missed one while I was in London. If anybody decided to look at ACID2, please file bugs. Maybe get the community to help as well; we have 2-3 weeks.
• brson: Are we at risk of not passing ACID2 on time?
• jack: Not that I know of, but I have not gone through ACID2. zindex is the last big thing.
• jdm: The before and after pseudo-stuff I need to follow up with, since I asked for some fairly big changes.
• jack: OK. At least all of the big work that we know of is in the review queue.
• simonsapin: Is auto table layout missing?
• jack: We need some piece of it for ACID2?
• simonsapin: I thought we didn't, but I was wrong...
• jack: I will look and see wha tI need.
• pcwalton: Need fixed first because it creates all the flows we need.
• simonsapin: Can use a basic auto using the preferred width for ACID2.
• pcwalton: Maybe someone should try to minimize ACID2 to find out where the little bugs are... I can?
• jack: Awesome: +1. A good thing would be to do that, create little test cases.
• pcwalton: Yes. ACID2, as SImon points out, is not friendly. Everything explodes if something is wrong.
• jack: Yes, unlike ACID1. And ACID2's flow tree is probably an exercise in frustration

rust upgrade status

• larsberg: i'm in the middle of gfx crate. i've figure out what most of hte big changes are and most are fairly mechanical. the more challenging areas are tobytes chaing to hash. also, lifetime inference is resulting in ICEs and niko doesn't have a good solution for until he rewrites the lifetime inference in rustc. after i get servo crate done, i still need to do linux and android, so it won't be landing tonight or anything. It will land with a bunch of E-Easy issues, because rustc added a bunch of new warnings and lints that aren't all trivial to fix.
• kmc: we should open issues for making some of those warnings into build errors.
• jack: I'd be fine with warnings as error except for bindings...
• kmc: Can you turn it off?
• jack: It turns it off globally...
• jdm: We turn off the warnings we allow on a per-module basis... but I don't know how that interacts with turning warnings into errors.
• kmc: I think that should work.
• jack: I was going to turn off the warning before, but jdm was worried that it was not granular enough.
• kmc: I think the script crate builds with no warnings; there were no warnings from the actual servo crates.
• jack: Then jdm must have resolved this before. I can file a bug to turn on warnings as errors. Maybe after the lars-rust-upgrade comes.
• kmc: We have them on in some of the dependencies. We should probably start with servo's crates and make sure it doesn't break make check. Can put an attribute in each crate for it instead of messing with compiler flags.

Plan notes

• jack: incremental layout, HIDPI work, and some benchmarks probably not coming in Q1. Some other random bits like nightly builds, too. The other thing worth discussing is I talked with Samsung about ACID3 being stupid. They agreed that we can replace it with something else - we need to figure out what that something should be. Roc suggested 100 random wikipedia pages as a new ACID test. And a variation of that is to analyze the 1k popular websites and build an ACID test from those.
• kmc: Chrome has a bunch of usage statistics on a page with those CSS features. Just wikipedia probably only tests the mediawiki features.
• pcwalton: It already looks better than just about every other webpage. Some is because wikipedia is pretty simple. The rest is that we don't support SSL. Frankly, we mainly test on wikipedia. Once you have ACID2, you have wikipedia.
• jack: Some ideas here (with our q2 goals) are bidi text, writing modes, CSS OM, forms, load/unload events. Maybe build it around the features we plan to make in Q2 as well?
• kmc: load/unload would got with document lifecycle stuff, right?
• jack: Yes. So if you make tests, we can just turn those into ACID.
• kmc: Should bidi get text shaping correct? No RTL scripts... maybe hebrew, but not arabic.
• jack: Yes, we definitely have to get it working.
• kmc: It's not just RTL for latin text is what I mean; we need to support other scripts.
• jack: Yes, we should test with a page with arabic and english place names.
• simonsapin: Two parts. One is RTL layout and the other is BIDI, which is test in two directions in one line. Basically, it relies on Unicode, but there is some contorl. You can say "this span is BIDI isolated," etc.
• kmc: Then, RTL layout, BIDI layout with overriding of styles, and text shaping.
• pcwalton: And pagination to consider. Probably a good idea to at least think about it...
• jack: In my notes in 2014 plan, I have that fragments should move up to Q2.
• simonsapin: Isn't shaping solved by harfbuzz?
• kmc: We're not interpreting the output correctly. There are some open bugs about that. I don't know what needs to change - it might be easy. We might also need font work to get working arabic fonts, but that might not be so hard to get a demo-quality implementation working.
• jack: Sounds good; we'll be talking about it a lot at the next workweek, I assume. Any other stuff?

gecko layout work week

• simonsapin: While I'm at the layout workweek, is there anything else I should ask the Gecko engineers where you want input?
• jack: Fragments and pagination would be a good one.
• pcwalton: Sounds like CSS FRagmentation spec is tied up with Regions and is in a lot of flux. I wonder how much is actually going to happen and how much is not likely to happen at this point. Clear we can't implement the spec (it doesn't work), but how much should we?
• simonsapin: What do you mean?
• pcwalton: Some parts do not terminate. dbaron said it needs to be fixed somehow...
• simonsapin: Region is just one case. Even without them, we can still have fragmentation in vertical and paginations.
• pcwalton: I'm just wondering where is the line in the spec between what is going to happen vs. what is not.
• jack: Roc probably has a good idea. I think asking him is a good start.
• kmc: Yes, if blink is not going to implement part of it, presumably we should not either since nobody will use it.
• jack: Yes, lots of pushback on getting rid of regions for them, not sure if they're going to continue.
• kmc: Should break out work to actually implement the feature vs. work to ensure our design could support it
• simonsapin: Isn't vertical implemented by many browsers?
• pcwalton: Yes, we definitely need multicol. Not sure about full regions.
• jack: Pencil in multicol and get feedback from Roc on whatwe should be doing.

CSS on GPU

• pcwalton: For GPU you need it very parallel (we have) but also need high arithmetic intensity, too. Problem with CSS is that it's memory-bound and not lots of complicated computations, so the GPU gets swamped in memory accesses. Don't know if this will change with newer GPUs (so excited to see on AMD APUs). For now, does not look that promising unless we can address some fundamental problems. Right now, we only read one DOM node per cache line (128 bytes). Unless you can coalesce more than one, you've already lost to the CPU because Intel's caches are so good.
• kmc: We've talked about succint data structures for the DOM...
• pcwalton: If I could pack them tightly together, I'm sure I could get speedups, but didn't allow that because I didn't know how to realistically do it.
• kmc: Nice to get a best-case number to see what our upper bound is.
• pcwalton: What Leo talks about with packing DOM nodes, it's definitely important for GPUs. Not on the CPU, because it just works. GPU, though, really wants to have a lot of code to run. Can usually get it by filling multiple work units by filling the cache delays with work. But if the work units are all in separate cache lines, you will have a hard time. Basically, it has only one memory read per operation, so it basically replays the memory loads, killing perf. Not like 10x slower than the CPU; it's faster than sequential. It's just that with four Intel cores with great caches, it's hard to beat that.
• kmc: Other than selector matching, what else should we try on GPU?
• pcwalton: Maybe layout constraint-solving. Again will want to load multiple frames in one cache line, but might have more options there because it's not JS-manipulated, so we might have more options. It all needs to be dynamic and incremental, though. Would be easy if we didn't worry about incremental reflow...
• kmc: Also, COW DOM. But that won't happen with flows, which helps.