Skip to content

Meeting 2015 03 16

Patrick Walton edited this page Mar 17, 2015 · 4 revisions

Servo Meeting 2015-03-16

Agenda items

  • Getting the Android "nightly" working? (larsberg)
  • Things to do next quarter (larsberg)
  • Maybe schedule week-long: 1) perf bash; 2) PR review bash; 3) testing bash; etc.
  • Coordinate resolving rustup blockage (jdm)
  • https://etherpad.mozilla.org/rustup

Attending

  • Manishearth, mbrubeck, larsberg, jack, savago, brson, pcwalton, gw, kmc, azita, jdm

Android nightly

  • larsberg: There is now an Android "nightly" build being published to S3. I haven't publicized this because it doesn't actually start up due to https://github.com/servo/servo/issues/5145 - we fail to load OpenSSL libraries. mbrubeck and gw and I will look at this. In good news, it's under 14 MB, compared to ~200MB for the debug builds that we've been creating in development.
  • jack: How big is FF on Android?
  • mbrubeck: 15-20mb back when I was working on it, probably larger now.
  • brson: 35-40mb these days.
  • gw: Including mozjs in servo?
  • jack: Yes.
  • Manishearth: Will we stick an emulator on that?
  • larsberg: Plan to stick an emulator on there both for android and gonk, just to see that they don't crash. Will have to wait for next month.

Next quarter

  • larsberg: Q2 deliverables will be coming soon.
  • larsberg: Also, it might be interesting to spend a week as a group either focused bashing on perf/PR backlog/something like that. When we've done that historically it's been quite productive (eg. rust upgrades/last minute demos) and it's a shame that they've been limited. Could be good to think about for next quarter.
  • jack: This quarter we did a lot of work on adding new features to platform; would be good to focus on usability improvements now. Could make sense to alternate between these two metagoals, especially testing. Perf is more important than a single week. Testing could benefit from everyone spending a week adding more reftests, or filing bugs, or fixing WPT failures.

Perf / testing

  • gw: Could put automatic regression testing on perf? Often we miss these failures.
  • jack: I just fixed this memory leak. It would be nice to have an upper limit that fails the build if we go above a certain amount in GotG for example. Currently resizing is busted for incremental reflow, and it would be nice to have caught that. Every feature that's not tested in Servo breaks.
  • kmc: Eagerly open up needstest bugs, even E-easy. Often identifying what we need is the hardest part.
  • larsberg: Gecko folks say doing logging and having real people look at it works better than automatic gating, due to unreliable computing environments. Collecting just basic data would get us far.
  • jack: Something on the builders could collect this and leave a comment on the PR if >X% change in something measured.
  • kmc: Graphs showing measures in past X days would be great for monitoring problems.
  • jack: Any comments in shift on focus for next quarter?

Usability / compatibility

  • kmc: What constitutes usability?
  • jack: Stuff like incremental layout. glutin was a mixed bag when cutover happened.
  • mbrubeck: So stuff that prevents dogfooding?
  • pcwalton: I want to take time to fix layout bugs.
  • kmc: gw talked about creating wiki page that explains how to address those problems.
  • jack: I think of usability as shell-related stuff, and technical debt we've incurred.
  • kmc: Agree, this is a good time for that. Makes sense in conjunction with improving testing. We're better at testing things now than we used to be.
  • larsberg: I'm behind it if we have specific goals in mind - pages that compare well against other browsers, for example. I worry that shell apps are infinite sinks for improvements.
  • jack: gw is working on browser.html stuff, and there's related layout bugs there, so that's the sort of thing I'm talking about. Other things - jquery has been subject of discussion for a long time, but it still doesn't work. Or react, or other dynamic API layers. Better milestones than acid goals.
  • Manishearth: Last I checked jquery was close.
  • jack: Still missing innerHTML, CSSOM stuff, etc.
  • gw: React is a dependency of full browser.html project, so could be good target.
  • kmc: Is sandboxing/e10s good focus for q2? I have ideas for how we could pursue high security mode. Don't know if that's a niche we want to pursue. Would go hand in hand with fixing up known high exposure avenues. (highly desired for the 2015 goal of shipping a tech demo)

Layout

  • pcwalton: In terms of layout features, biggest missing thing is flexbox and svg. Our breadth is good at this point, but we're quite buggy. Most of the brokenness is probably bugs, rather than full missing features.
  • kmc: We can do static SVG using the polyfill, rather?
  • pcwalton: That does dynamic, too.
  • kmc: Is there a big testsuite?
  • pcwalton: There are a lot of tests. Don't know how automated.
  • kmc: What's the library?
  • pcwalton: CanVG. Major thing we need is the ability to use MutationObserver in order to get DOMEvents to update the document. Questions about what thread it should use...
  • kmc: And ShadowDOM for correctness?
  • pcwalton: Probably not a big deal in practice. I'd like to run it off the main thread, which ties into some of the new CSS Houdini stuff.
  • jack: I'll try to send an email this week with some of the ideas I had. Probably makes sense to keep a couple of people extending things as they have been.
  • pcwalton: In terms of layout I'd like to keep flexbox on the table. We don't have many big features left; I'd rather have fast layout than multicol, for example. For pagination, pages won't break because you can't print them. While nice to have, they're not critical for dogfooding or demos. Their use comes from being a feather in our cap, and to future-proof the architecture.
  • kmc: And future-proofing the specs. We want to be right on top of the houdini stuff to avoid parallel hazards. Might be better to go after new features that aren't widely-used for that reason.
  • pcwalton: Been having houdini conversations with roc/simonsapin; remain skeptical about perf benefits of houdini features, but shouldn't be parallel hazards there. One that is quite relevant is the ability to do some DOM manipulations off the main thread.
  • kmc: Animation workers?
  • pcwalton: The evolution thereof. Growing consensus that we want the 60FPS web to be driven by an off-main thread controlling things like animations. We're less limited in the properties we can animate in this way.
  • kmc: Some JS that responds to zoom event, etc.?
  • pcwalton: Yes.
  • Savago: In last WebKit meeting there was a mention of Houdini - they have no plans to implement anything other than text measurement because of concerns about performance.
  • pcwalton: I also have concerns about implementing full layout algorithms in JS. People seem to think that makes it fast by default. The ability to animate properties off the main thread seems like the clearest win. It's strictly more power than before.
  • kmc: If other engines implement this and the set of supported properties is much worse than servo, it gives us something of an advantage. Especially if developers / libs fall back to on-main-thread in other browsers.
  • pcwalton: Twitter uses on-main-thread CSS transitions.
  • kmc: Yeah, scrolling gets really slow. That'd be a great Servo demo.

NCSU reviews

  • jack: PR review bash might be a good idea for when the NCSU projects are coming due. When is that?
  • jdm: Not as bad as last time; just two groups. In a couple of months.
  • jack: Still might be nice to schedule it then, though. Handle those groups and clean up the PR backlog.

Rustup blockage

  • jdm: Upgrade going well. One problem is where workqueue things are no longer sendable and seems scary to us all. Can somebody look into it?
  • pcwalton: I will this evening.
  • jack: Linked in etherpad? https://etherpad.mozilla.org/rustup
  • jdm: Yes. No particular information about the Send blockage, but If you build, it will not build layout because of the Send problems.
  • kmc: Raw pointers?
  • jdm: Maybe...
  • kmc: That's usually why things become non-Send.
  • jdm: That was the case with the last Rust upgrade. This is a NEW Rust upgrade! That's the only thing blocking the rustup.
  • jack: Are the PRs listed in the etherpad awaiting review?
  • jdm: All open and potentially awaiting review. Just generally not merging to avoid having to backport things if we have a long-lasting rustup.
  • jack: If we're on layout, just have a few things left to fix up... maybe just the servo/main crate?

PRs to land soon

  • jack: What's waiting to land? pcwalton?
  • pcwalton: Most have landed. Some code changes to transforms. I think sandboxing needs a lot of work; can happen after the rustup. Needs a port to gaol instead of the in-tree stuff. Needs a dependency on bincode. Some displaylist fixes. At least three things blocking it; there's a good amount of work.
  • jack: Anybody else have PRs we want to land?
  • gw: Mine just landed.
Clone this wiki locally