Skip to content

Meeting 2016 03 07

Jump to bottom
Lars Bergstrom edited this page Mar 7, 2016 · 1 revision

Agenda items

Attending

  • brson, mbrubeck, nox, jdm, jayflux, manish, ms2ger, larsberg, ajeffrey, simonsapin, till, jack, edunham,

Last week

Windows CI

  • larsberg: We had a big push last week, and Manish landed the final changes this weekend. We will now build Windows CI immediately on PRs, and it will build on the auto branch like buildbot does. Appveyor is like Travis but for Windows. If anybody has issues, let us know in #servo. There are also instructions on the mailing list for how to connect to the build machines if you have windows-only issues.
  • brson: Does homu gate on both travis and appveyor?
  • larsberg: Yes. On the main servo repo, we gate on buildbot and appveyor. Travis is only used for immediate PR feedback, so we don't need to gate on it. On other repos not yet.
  • brson: So rust could steal your homu and gate on travis?
  • larsberg: Yes.
  • jack: How many prs have landed since we started gating on appveyor?
  • larsberg: 4? 5? We're currently using 4 concurrent builders using their premium infrastructure. We're currently doing too many rebuilds, so we have at least two unnecessary builds for each PR merged.
  • Manishearth: We could use environment variables to do dummy builds for certain cases. I have some ideas for the other cases, but it depends on the events that are exposed.
  • larsberg: Definitely the smoothest major CI change we've rolled out.
  • jack: On the double auto push, homu used to do a thing where it would push the commits and then merge, so there would be two separate events. This was fixed and buildbot only sees one event now. Git push notifications were the case of the double notifications. Don't know if this is a regression or something appveyor is doing differently.
  • larsberg: There was a weird thing about the github/buildbot webhooks that meant that the ordering of events can cause issues. NEed to do some testing, but we always have multiple PRs in the queue.

Firefox performance fix

  • larsberg: If using anything besides FF stable, heycam + others gave the reviewable folks info about performance problems. Performance should be much better in Firefox, even on large PRs. If there are any problems, let me know!
  • jack: Even before this one, all of my performance issues had previously disappeared, so this is great!

Maintainers

  • nox: I am now a reviewer on bincode. We should be able to bump versions reliably. Also, we should be able to publish ipc-channel now.
  • nox: rust-bindgen is the last dependency where we have some issues with wanting some more maintainers.
  • simonsapin: Did anyone ask for ipc-channel on crates.io?
  • nox: No, but I think we'd manage it better. I know that not publishing means there are less roundtrips when landing fixes, but I think that we're better with crates.io dependencies than git ones.
  • mbrubeck: I've seen people on #rust asking about IPC libraries, so there's probably demand.
  • jack: It doesn't churn too much, so I think it's a good candidate. I also doubt anyone will do the work to make a better one, since it's got a ton of features implemented. So let's go ahead and do all of this. Is serde a dependency? I think pcwalton is a maintainer there.
  • jack: rust-bindgen is more complicated. I think there's upstream, mwu's fork, and till's fork. If the upstream maintainer is non-responsive, we should canonicalize one of the forks and move people over to that.
  • till: Mine is not different from mwu's. There are mainly just rebases on top of upstream master. However, mwu said that upstream essentially said that we could just take over / run the project.
  • jack: Maybe the thing to do is ask crabtw if we could move the repo to the servo org. Then we can worry about it all from there. I don't know if any downstream dependencies depend on rust-bindgen or if it's just run there.
  • till: Move to rust-lang?
  • manish: rust-lang-nursery?
  • brson: Maybe not since it's maintained by Servo?
  • till: My long-term thinking is that if we can stabilize the C++ bindings generation, that would be good for Rust.
  • nox: I opened an issue last week in the repository asking for push rights. We'll see what happens.
  • jack: I don't know if we have a problem maintaining one in the rust nursery instead of the Servo org. Is it hard to get push access in there?
  • larsberg: I'm worried about having all the Servo CI pointed at rust-lang-nursery...
  • brson: If we start intermixing our CI, that could get ugly to manage.
  • jack: The long-term goal is to use rust-bindgen to automatically get updated bindings when SpiderMonkey changes upstream.
  • larsberg: A lot of rust-bindgen fixes have required LLVM fixes. So at least until that lands upstream in tooltool, if we keep adding C++ features we'll need to run CI against custom LLVM builds. And then we hit Travis timeouts from building LLVM.
  • till: Were there additions last month that required LLVM changes?
  • larsberg: I don't know; I'd need to ask mwu.
  • till: The fixes he did for his first SM update have landed and been deployed already.
  • larsberg: But I suspect as we add more features to bindgen we'll need more LLVM patches.
  • till: At least on our Try servers we can push changes to LLVM quickly. So maybe it does make sense to get that automation in place sooner rather than later, and have that be our CI.
  • jack: The easy path is to first get somebody with push access, get the original repo up to date, then work on getting it into the servo repo and automation. nox, if the maintainer reappears can you ask him about moving the repo to servo?

Unforking servo-glutin

  • jack: Everything is ready to unfork - just need to do it, right?
  • nox: I don't want to do it (don't have Linux), but wanted to bring up that we should be able to do it now. And ask people to stop landing things in servo/glutin first.
  • jack: I was going to try to do the unfork last week, but got busy. paul also has push access, so he might do it.
  • mbrubeck: In portland, we also talked about how we keep adding application stuff to glutin, that seems not very game-focused. We don't want to fork, but maybe we can have an extensions crate?
  • jack: We tried last time, but new mouse button events really don't go well in extension. I'd like for people to get reviews from tomaka and to do more documentation, etc. in the patches we upstream. I've noticed in glium that everything they did there is well-documented. Hopefully not much more.
  • larsberg: There's a lot to do for Android...
  • mbrubeck: That's mostly not Servo-specific, though; games and everyone else will benefit from application lifecycle support.
  • nox: On documentation, we have the same problem on rust-bindgen - we have a lot of additional code, but it's a bit low on documentation, tests, and commit messages.
  • till: I agree.
  • jack: Should we talk with mwu?
  • nox: Maybe, but he's busy. I've started documenting and upstreaming some of the bindgen bits.

Crate management and mach build

  • nox: Want to have components/servo/Cargo.lock be removed and make servo a proper library crate. Then there would be a ports/ whatever subdirectory. Then, everything is compiled the same way (all of the toplevel projects are in ports/).
  • jack: main.rs moves under ports?
  • mbrubeck: Kinda have this inverse relationship between glutin_app and servo crate - could probably flip that.
  • nox: Also, geckolib needs to depend on util because it's where DOMstring lives and stuff needs to be defined on it, but we need a feature on the crate so we don't depend on spidermonkey. If we do this change, we won't have to rebuild util when we do build-cef on the machines. But, we'd need to refactor the style crate a bit to remove its dependency on DOMString. But, the two possible refactorings are not agreed upon by people.
  • jack: Seems fine to move things and do a util split.
  • mbrubeck: I like making servo just a library crate and moving the binary crate to ports/. Also wanted to mention:
  • mbrubeck: Cargo workspaces RFC is coming: https://github.com/rust-lang/rfcs/pull/1525
  • larsberg: Gives us one cargo.lock, which would make me very happy! Still a lot more work to get everything to work.
  • nox: It sounds like we'd want some sort of "world file" (?) for the Cargo workspace to define which crates/versions are possible to depend on.
  • nox: I think we need to see how features interact with crate compilations.
  • simonsapin: Comment in the RFC?

browser.html hackathon recap

  • jack: The whole browser.html team plus myself, gw, pcwalton, and mbrubeck met in portland. Want browser.html ready for the June workweek in London. Fixed tons of bugs, many related to animation performance. Key takeaway is that almost everything is running locked at 60fps. I believe browser.html is now smoother than the gecko version. Other big thing is that browser.html now publishes tagged versions as cargo packages. Servo now depends on this, so as of last friday you can do ./mach run -b and it'll run the browser.html that it depends on. Should work out of the box! Multiple tabs, animations, etc. Even just the URL bar makes things much nicer.
  • jack: Focus from here out is on fixing layout bugs in sites we want to work in nightly (github, wikipedia, etc.). Remaining performance stuff. New tab page, fixes to the close window, there's no back button (and it doesn't work in Servo anyway...), etc. There's a tracker for all browser.html high-priority bugs. Good place to try and get more new contributors with frontend experience involved since it's mainly JS, etc.
  • jack: Other big push in Servo is that we need to look at page load perf issues. After some investigation, the biggest hurdle is OMT / speculative HTML parsing so that we can start doing preload of other resources. This is where you see the page stall on initial loads. So, yes, June is the big version for the world.
  • larsberg: Mobile?
  • jack: Currently it's limited to desktop; they're doing interaction design that doesn't really work on mobile. I talked to Gordon about doing a lite version that would work on Android. We could maybe start working on that in London, after the desktop work is fairly complete. The biggest problem is going to be getting the keyboard integrated so you can type in the URL bar.
  • jack: The UI design is fairly different from existing browsers, so it takes some getting used to. I encourage everyone to play around with it. The short-term goal is to get simple usage with a few tabs very easy. Longer-term will focus on features needed for power users, like full support for tab management and keyboard shortcuts.
  • jack: Other big news is that pcwalton and gw have a huge amount of design work on "WebRender 2." The basic design right now is that we draw every pixel of every frame, but there's a lot of overdraw when things overlap. This shows up in the moiré demo where there's a lot of overlap. Also we don't have enough information to do subpixel antialiasing. gw had a great idea to solve both of these problems. The prototype he built uses a ray tracer to trace through all of the objects and draw each pixel only once. That should lead to new features like subpixel AA and also more consistent performance.
  • jack: pcwalton also worked on optimizing display list generation after mrobinson's flat display list patch landed. That should fix some cases where display list generation was a bottleneck, and should also fix issues we were seeing with IPC channels. We should check whether we can start running tests in debug builds again.
  • Simonsapin: It's about 5x slower. Debug mode is hardly usable. I wonder if we could have something inbetween? Level 1 optimization or optimizing some crates?
  • jack: Yeah, a lot of parts of Servo get absurdly slow in debug mode. Selective compilation didn't help when we tried on ipc-channel, unfortunately.
  • larsberg: We should check the debug asserts. I'm betting we are doing some massive printfs / debug output.
  • mbrubeck: Could do builds that are optimized and with assertions enabled...

heapsize first block

  • nox: We would like to have heapsize support for {?}, but we can't do that without putting heapsize in Rust. So I'm requesting getting the functions that give us the allocated size in Rust. This will prevent our dependency on the internal symbols related to malloc. What's the next step?
  • jack: I'd take advantage of your trip to MTV next week to ask people about it.
  • simonsapin: Can also ask pnkfelix, here in Paris.
  • jack: Next week is nox's first week, btw!

intermittent test failures

  • mbrubeck: Over the last couple of weeks. nox found the root cause of several of them and I wrote patches. Basically, we're in much better shape, but we'll need to keep an eye out. Also, there are a bunch of disabled tests... I'll keep working on fixing.
  • jack: Another thing that might help is that now reflow blocks on page load, so we won't see FOUC in as many cases. Should also help with generating PNGs, since sometimes they were generating too early. Sometimes, though, style loading doesn't block document load. Once we fix that, we should have more intermittents down.

promises

  • larsberg: I saw some stuff land in teh bugzilla bug...
  • till: I landed the small bits, but I have 25 more patches to get reviews for and there's an intermittent crash. Then, I have to get devtools people to fix two things for me. THEN, promises will land. It's ridiculous how much this touches... on the plus side, I have a good idea how this all integrates into a browser engine now. A barebones integration to servo should be quikc.
  • larsberg: Do you need help getting reviwers or other help from the gecko side?
  • till: It looks like things are on the home stretch...
  • jack: Suggestions for things to use themonce promises land?
  • larsberg: Unblock stuff that is working around not having promises.
  • jdm: Can just do bluetooth.
Clone this wiki locally