Servo Meeting 2014-02-10

Agenda

String interning. Can we give ryanhc tips to revive https://github.com/mozilla/servo/pull/1135 based on our new hash table, etc.?
zmike on embedding plans
jgraham on document loading (and beforeunload event to cancel navigation) plus yieldable script engine design
acid2 status
testing status (larsberg)
- what's blocking linux?
parallelism status (pcwalton)
- numbers for wikipedia?
- what's left to do?
E-easy bugs - how do we make them more available?
Rust upgrade
Code documentation
JSManaged impact on DOM bindings?
- relations with DOM exception handling?
TNode > AbstractNode problem (query selectors)

Attending

jack, ibnc, larsberg, kmc, jdm, ms2ger, zmike, jgraham, simonsapin

string interning

jack: There's a PR 1135 for this. Can we revive or close this?
larsberg:
pcwalton: do we need concurrent hash map for it?
jack: I think we might not need it.
simonsapin: the PR was not thread-safe. Then we talked about whether we shared it across tasks or not. I'm not sure we had a clear conclusion.
pcwalton: Because the CSS parser runs in layout, it's got to add things to the intern table, so does the HTML parser. So it needs to be threadsafe.
simonsapin: I think we are passing the CSS strings between tasks.
pcwalton: but separate from the html parser, so it needs to be threadsafe. The concureent hashmap needs a new rust upgrade. that's blocked on @mut removal. And that's blocked on jsmanaged, which is blocked on jdm...
jack: no, it's blocked on me - jdm did his part.
pcwalton: Once we land those, we'll get the new mutex and can land the concurrent hash map (and parallel flow construction). If we try to use the concurrent hash map without the rust upgrade, we'll be deadlocky.
jack: is there a concurrent hashmap in rust?
pcwalton: I wrote one. It uses OS mutexes, though.
jack: In rust or servo?
pcwalton: Servo first and then upstream to rust.
jack: update the PR in the summary with our plan?
pcwalton: OK.

embedding plans.

zmike: I work for Samsung and have landed some stuff like task renaming. The original embedding PR called to use the WebKit embedding API. Chatted with pcwalton & larsberg about using the chromium embedding framework. Doesn't build on linux, but there are some binaries. My plan is to hook up servo to the simple example and eventually grow to the whole API.
pcwalton: CEF has a C api. Is that a little easier? Rust does not support exporting C++ APIs and CEF is normally C++. So, it may be easier to implement the C API with the C++ API as a wrapper around it. Rust is not going to support C++ APIs soon because it's pretty complicated, so it may be easier to work on the C API for the CEF instead.
zmike: I was looking at the symbols, and all of them are just the C API anyway, so that's where I started.
pcwalton: May be a little bit of C++ wrapping to do, but as long as you have a stable C API, you can export symbols, mark no_mangle, and you can link from C
jack: Chrome Embedded Framework insulates you from google's API changes?
pcwalton: yes, and it's heavily used in industry. Steam uses CEF, Adobe Brackets is, etc.
jack: So we implement both sides of this? Or there's some browser that we can use?
pcwalton: "CEF Simple", which is basically the minibrowser from webkit. Same story as webkit, but more industry support.
jack: Would we be exposing a CEF API?
pcwalton: Yes, we're a drop-in replacement for CEF.
jack: Reason to abandon the Webkit one just because that train has left the station?
pcwalton: Yes, that's how I feel.
jdm: do both!
pcwalton: no. Idea was just to be pragmatic.
zmike: I don' tknow when I'll be completing this or anything; will just keep the ticket updated.
jack: sounds good!

document loading and beforeunload

jack: so we're not doing anything close to compliant currently
jgraham: the point mentioning it is that it's a special case. It can pause the onload operation and pop up a dialog to allow cancellation of navigation. You have to be able to unwind the whole load process. In presto, we found that if you don't design for this particular case, it's basically impossible to retrofit.
jack: Is there a reason you can't just run beforeunload before you do anything?
jgraham: I don't know how much state you have at that point. But...
jack: form submit, page load, normal navigation, etc.
jgraham: Have to be careful that you're not throwing away resources associated with the old page before you go to the next page
jack: Does it return a result?
jgraham: It pops up a browser-level dialog (browser sets it), it's the "are you sure you want to navigate away from this page?" There's not much developer-level control, but it returns the True/False value to tell you to stop the unloading or continue it.
jack: Are we doing any work around document loading right now? How do we make sure that we get this right?
jdm: We're not doing anything specific around changing our implementation or designing it at all right now.
jack: Do we need it for event stuff for ACID2?
jdm: Don't need the event stuff. No dependence on having a proper load event. Can probably...
jgraham: ACID2 is almost entirely layout. No script component, so it's just not exercising this code at all. But to run any kind of real web app, you have to get this stuff at least more right than we do at the momenet. And then for the google docs level is even more work.
jdm: Probably required for ACID3.
jgraham: Definitely. At the moment, we don't even really support external scripts. We just load and run them at completely the wrong time.
jack: I'll flag this as Q2? Should I add a note about this in a document loading issue?
jdm: Not exactly an issue there right now.
jack: Can you create it?
jdm: Yes.

acid2 status

jack: tables is waiting for me. Did relative positioning land?
larsberg: yes.
jack: generated content?
jdm: pseudo broke thread-safe parallel stuff. pcwalton, if you can answer the questions, that would help...
jack: they're accessing parents and siblings, both of which are not OK
pcwalton: can only access kids and yourself. You can have limited access to siblings/parents if that pass is not touching it. It's easier to just not do it, otherwise to do it safe you'd have to have a RestrictedThreadSafeLayoutNode... it would not be fun.
jdm: Instead just push down data from parents to children?
pcwalton: yes, take advantage of the cascade. Can have fake CSS properties not exposed to the content. There's nothing evil about this; it just lets us push them down.
jdm: I believe it's arbitrary collections of rules in order to get the :before and :after style from the parents
pcwalton: I'll have to look into it.
jdm: I'd appreciate your thoughts.
pcwalton: I'll probably have to think about it for a bit...
jdm: I was mainly looking at the DOM-like things, so the layout portion of this PR is beyond me.
jack: background-image?
larsberg: SimonSapin did the CSS review and I did the code part
jack: position: absolute, z-index, etc.?
ibnc: I'll have a PR up soon to help nail down some of the issues there.
jack: z-index is already ready, since we have multiple display lists
larsberg: pradeep has been coordinating with us on that in IRC and issues
jack: neg margins, overflow, min/max height & width, nothing yet. overflow seems to be broken in some cases on WPT. floats in front of in-flow stuff just falling out of displaylists?
larsberg: I don't know who's looking at it from Samsung side and neither have I

testing status

jack: content & ref tests?
larsberg: they work! but not on buildbot because of missing truetype fonts
jack: I will ping bhearsum. Most of our bugs have, "I'm trying to find someone to own this..." The next testing stuff will be the web platform tests. jgraham did a harness in the mozilla tree, so we just need to pull that over.
larsberg: are they basically ref tests?
jgraham: there are some, but it's mostly javascript-based. The runner I have hasn't landed in mozcentral yet, still on ??. I haven't been checking that I didn't break anything in servo as I keep trying to make it work better in gecko, but it should be straightforward to get working again and integrated.
jack: I'll see if there's a bug for that. I sort of know what needs to be done to get it integrated, so I'll look into that.

parallelism status

jack: Saw lots of numbers go by. Where are we at?
pcwalton: Parallel style recalc. We're already great on reflow, but were bad on matching, cascade and flow construction. On the rainbow page (not a great benchmark!), we're faster on sequential than Blink but don't get any parallelism gains. Part of that is because the LRU cache, which we're now also using, just happens to sequentialize the access. I'm not sure how representative that page is, though. if you disable the cache, we're a little slower than Blink sequentially but faster in parallel. 2.3-2.4x improvement on 4 cores. If we get rid of the leaf set, could get to 2.9x. I noticed you have wikipedia there. We have no way of benchmarking wikipedia or any real site because of font collection loading, which we do during style recalc. I don't know where the other browsers do it, but because we do it during style recalc, it kills our numbers.
jack: How on rainbow page?
pcwalton: There are no fonts. It's not a great benchmark for many reasons; it's meant to be a test of a lot of nested blocks. It's susceptible to optimizations for style sharing. Blink's works well, webkit's does not.
pcwalton: For what's left, we need a rust upgrade for the hashmap for parallel flow construction. Need to figure out how to do parallel display list construction. Will probably involve rewriting some of the display list construction code.
jack: Nobody's touched that in a long time.
pcwalton: Yeah, just need to get it before it gets bigger. We should also turn tiled rendering in parallel back on.
jack: I was mentoring that project when we were in Suwon. I will ping them to see how it is going.
pcwalton: Yes, the system is more threadsafe now, so it should be easier. Assign widths is also still sequential; should be trivial. Removing the leaf set is another idea, which should resulting in some good gains (15%-ish). Damage calculation needs to be redone/rethought. I'm still not totally sure on how that fits into this. I'm not even counting it as part of style recalc. But I think that an optimized style recalc will not have any damage recalc in it because when you create a new flow, you create it fully damaged. We'll have to think about how we do that.
pcwalton: Seth Fowler is starting to think about the AMD integrated GPU/CPU things. Fully cache-coherent, so you can use the GPU to work on data you malloc'd on your CPU, which is a big deal. Now we can really do layout on the GPU! We already have some Rust GPU backend stuff. Not going to put a lot of time into this, but going to start doing some preliminary experiments. They're 512 core GPUs, which is too attractive to not investigate.
jack: Ping tim terriberry about that. We have issues in daala on memory bus bandwidth that don't go away...
pcwalton: I just wanted to write a fake C++ program that does bubble widths on some fake values and test the performance, scalability, etc. to see if it's worth it.
dherman: How much of a sense do we have of how much this is the future direction GPUs are moving in? Is that where this is going?
larsberg: intel is trying to bring it onto the die or at least as far as possible.
dherman: we should try to find a way to rent time on a machine
pcwalton: these things are cheap.
dherman: do it!
jack: otherwise, mine bitcoins to fund gittip on servo.
jack: I'd like to fix what we can fix in the font stuff to get numbers from wikipedia. Can we get a commandline flag from the profile to get a JSON output? Then buildbot can run with the metrics, bors can push the numbers into tickets, etc.
pcwalton: I have some wikipedia #s. Selector matching gets 2.3x parallel speedup.
jack: We'll want to show off wikipedia accomplishments.
pcwalton: One more thing! I think we can get more parallelism on floats. If there are any float kids on a DOM node, we just give up. If there's clear:, we can do more in parallel. We're just too conservative. Somebody needs to audit that code in layout.
jack: Spec said floats don't go past containing block but implementations do?
pcwalton: Definitely do.
jack: Hrm, I wonder if being spec compliant breaks the web...

Incremental layout

jack: what's the story here? have we looked at it at all?
pcwalton: I think it's kmc's domain and I don't know how it works right now.
kmc: all we have right now is tracking when CSS properties change if you need a reflow or just a repaint. Probably needs to be integrated with other parts of the pipeline incrementally.
jack: so with a color change, just build one new displaylist node at the moment?
kmc: We don't reuse display lists at all yet. We need to do that, and then it would work.
jack: Might be nice to have some timing on incremental stuff. Like changing color should be super-fast. Setting display:none, etc. Maybe a float property. At least we can start just timing CSS passes and then look at incremental flow construction. My thinking is that the incremental layout on the schedule is not display list incremental, since DLBI is in Q2? Concentrate on other pieces?
kmc: Yes, almost all the DLBI work is incremental display list.
pcwalton: Display list construction will go down massively once we only do the visible region + a little overflow. That will make display list construction basically not show up in the profile. It's super cheap in Gecko, too. It's just repainting lots of tiles without DLBI that leads to poor performance.

E-Easy bugs

jack: had a complaint the other day about this...
larsberg: I think of e-easy as for first users, not for somebody to do 80 e-easy bugs
pcwalton: gecko has "good first bug"
jdm: can mention on the user list
jack: Do we have a document? that mentions commenting in the issue, etc.
jdm: If you've been waiting for the time to start filing things that annoy you in the codebase as E-Easy, now is good. Trying to get a bunch of students hacking next weekend at GNUnify, and those would help.
jack: One thing is refactorings. There are tons that don't use ::new, but still the name of the type. This is definitely true in the network and graphics crates, so those are super easy. I'll try to go through and look at those. All the image cache task stuff is named horribly.
pcwalton: There's a discussion that maybe needs to happen about the layout directory needing to be factored. What goes there versus in css? In general, we have an issue that tasks are named after one of the many things that they do. the layout task does CSS selector matching, so everything (even unrelated to laying out boxes on the page) ends up in that directory.
jack: Documentation of the tasks seems like about all we can include...

Rust Upgrade

jack: know about jsmanaged. Need to de-@mut the rest of servo. Are there any more of these massive breakages in Rust going to hit us? They renamed a lot of APIs, etc. Would be nice to use the if_ok macros to take advantage of the returns of Result. Somebody not named jack should de-@mut the codebase.
larsberg: I'll do it.

Code documenation

SimonSapin: Yes! Feedback from the OSG group (glazou, especially). Servo is hard to get started with. One reason is that Rust is a stumbling block. Second is there is little documentation about how the code works and what's there is outdated. It would help to have documentation. e.g., what is an AbstractNode?
jack: That's going away soon! But we could document the tasks pretty thoroughly using rustdoc and then maybe the base datastructures like Flow and Node and JSManaged, then it would be enough. Those aren't super-hard to document, but hopefully it would be enough. After that, though, it's all details. Might also be useful to add a wiki page that breaks down a landed PR into the places you have to touch in the codebase to land e.g. a new CSS feature or DOM feature.
simonsapin: Quoting: "Need technical writers for Rust. Preferrably people without a PhD in programming languages."
dherman: This is an issue for Rust in general, that we have a lot of work to do documenting it. Chris Mills from MDN is leading that effort.

JSManaged impact DOM bindings

abinader: Hi, I wonder how JSManaged will modify the way we deal with Node/AbstractNode taken from codegen/bindings/*
jdm: JsManaged makes it much nicer. Should not have AbstractNode anymore. In general, it doesn't cause too many changes, though there are some new idioms...
jack: in the agenda, he asks w.r.t exceptions. I don't think we changed anything with those.
abinader: sorry, having problems trying to call the conf, so yes, I'm mostly interested in glue the DOMException interface and throwing it instead, but not sure exactly how this will proceed
jack: I will work with abinader's connection to the conference call. jdm, please follow up