Meeting 2014 10 27

Servo Meeting 2014-10-27

Reminder

Please update your status at: http://benjamin.smedbergs.us/weekly-updates.fcgi/

Agenda

• Final pass over agenda items / planning for workweek (larsberg)
• https://etherpad.mozilla.org/Servo-workweek-2014-11
• acid2 (jack)
• Intrinsic sizing of orthogonal flows (simon)
• string-cache and html5ever performance update (kmc)
• glutin update (gw)
• Quick infra update on split mac builds (larsberg)
• Parallel performance benchmarks? (larsberg)

Attending

• larsberg, pcwalton, Manishearth, jack, gw, brson, mbrubeck, samsung, simonsapin, cgaebel, kmc

Work week

• larsberg: The only thing I wanted to mention was that we should take one more pass over the agenda, since we need a final schedule for what we're going to talk about when. So if you have anything that's not on the agenda yet, get it in soon.
• jack: Is mrobinson going to be there the whole week?
• larsberg: Yes, during business hours at least.
• kmc: ride-sharing for the workweek?
• jack: Add a section to the etherpad and we can have people sign up if interested. There are several from the Samsung OSG coming from the valley as well.
• larsberg: Did we get arrangements on having a bus take us to the SF office for the day?
• jack: I requested it, but I'll ping her again. The Caltrain is also something we could take on Thursday to and from the SF office, including one back to the south bay that is OK after the meetup ends. Please do add anything you want to discuss, as we will put the schedule together this week.

ACID2

• jack: People in the community have pointed out that ACID2 has regressed. What is the status here?
• gw: I looked at it a couple week ago. There's only one issue remaining - that the nose is offset by one pixel. I looked into that, and there's an accuracy issue with rendering borders. I haven't looked into it. It is pixel perfect on Mac and Linux otherwise, and the reftest is running on both now.
• jack: On master?
• gw: Yes.
• pcwalton: I think some of the issues may be related to graphics drivers. Sometimes no other layers will show up with some devices or races with the compositor. I don't know of any races in the compositor right now, though. We could chalk it up to graphics driver issues, though I do not want to use that as an excuse. That said, if community members are seeing them, we should have them take screenshots and file them. Probably two issues: the one-pixel accuracy and one on layers.
• mbrubeck: One is just noting that the ACID2 issue is grossly out of date.
• gw: I should clarify: The ACID2 bugs that I fixed were related to the noscroll reftest that SimonSapin added, which just has the face and not the link above. I think when you have the full test, you might have some issues related to layers that mrobinson was going to look at.
• jack: Let's get those bugs filed.
• gw: I think mrobinson may have already fixed those.
• jack: Sounds like some minor bugs to file plus the tracker.

Intrinsic sizing

• simonsapin: I will send e-mail, since it sounds like a transmission across the vastness of space...

String-cache and h5ever performance update

• kmc: I did some event logging so that we can look at how we're interning atoms. We are handling 80%+ with no locks at all, so the various tricks help. On google,com, it's 95% because they minify things. That is also an interesting piece of performance advice to give to web developers. I also measured the overall time of the parse_html function before/after switching. It got a little bit slower, though not much on release builds. Almost all of the time spent during parsing is DOM manipulation, as parsing itself takes no time at all. Something about our DOM bindings being slow or perhaps we are doing reflows during parsing.
• jack: Debug mode is probably a good catch, since I think we were always compiling netsurf with release mode. It would be good to maybe start a wiki page on "how to make your pages fast in Servo." This observation about minification would be good.
• kmc: Yes, we also have lots of advice on parallel layout. Ideally, it would be part of the Servo DevTools, and they would give feedback e.g., that we were unable to intern strings. Noticing when we can't clear floats, etc. seems like a great thing for our tools.
• jack: I think we can probably generate those tools features from this list of best practices.

glutin

• gw: I've been working on integrating glutin, a pure rust alternative to glfw, which would let us do headless rendering without any X dependency. It should improve the reliability of our CI infrastructure. There's one race condition on Linux where 1 in 15 runs of Servo don't render correctly. If I can get it done on OSX and headless, it should be set to go in.
• gw: The viewport renders over top of the window title bar, and you lose the height of the title bar at the bottom. It's really strange. I've traced out the exact GL/GLX commands and it's no different when we work or not. I suspect it's got to do with ordering of those function calls.
• kmc: I used xtrace on Servo, but never found it helpful for crashes in Skia.
• gw: I'll take a look.
• kmc: I think the headless testing is just the start of cool things we can do! If I understand correctly, we'll have a mode that just renders into a buffer using software GL. That makes our portability much better, we can work around graphics driver bugs, and it's just a great fallback.
• gw: You literally get back a Vec. Only dependencies are on Mesa.
• pcwalton: Have you integrated that with the inversion of control in https://github.com/servo/servo/pull/3761
• gw: No, I thought that had already landed.
• pcwalton: Main thing it uses is the ability to post an event to the OS event loop from another thread. Currently, we poll. That might be part of the cause of some of the timing issues you're seeing. So, I have a branch that does that, but it requires that functionality and I don't know if it's available in glutin yet. You can search the branch for it.
• gw: It's not there, but I've made about a dozen PRs to glutin, and they're quite open to taking our patches. I did r+ that PR of yours, but it had a compile error.
• pcwalton: I'll look at it later. If you want to see the code for doing that on various OSes, you can look at what I cherry-picked from glfw upstream. It is fairly straightforward.

Split builds

• larsberg: We've split builds on Mac now. We also run wpt in a single process; which gets rid of most of the intermittents. Still some unsolved problems with intermittent failures, including different sets of failures on Mac than on Linux.
• jack: We need to get the right people together at the work week to find solutions. If the Python web server is buggy, can we just use a better server? Most of these failures are in tests that are just serving static files, no server-side logic.
• manish: Most of XHR is static files, but some of it looks at some specific parameters for special responses.
• jack: I can help track that down; it's probably more important than newbors.

Parallel performance benchmarks

• larsberg: It sounds like CSSWG is not quite convinced that parallel performance is important and viable. pcwalton has been working on DOM mutation benchmarks. Are there any other things we should work on to help make a compelling case for parallel layout?
• pcwalton: dherman probably has some opinions here. I know he didn't want us to make too much noise about benchmarks at this point. We want to be conservative with what we claim, and also I don't want to really start an arms race at this point. I think we need to wait and hear from SimonSapin what the mood at CSSWG really was. It sounded like some people might be receptive to our arguments. Also we need to look closely at the changes they're proposing; I don't know for sure how they will affect our parallel layout.
• IRC log: http://log.csswg.org/irc.w3.org/css/2014-10-27/#e484973
• jack: What information does CSSWG need from us?
• larsberg: I don't think they asked for specific info; it just sounded like people in the working group weren't sold on parallizability as a requirement in general.
• jack: While Dave says we shouldn't be publishing benchmarks, I think he means to a general audience. I think it would be appropriate to share data with a specific audience like the CSSWG. We need to convince them that parallel is important, or it will make our job harder. I'll add this to the work week agenda. And Simon will be there in person.

Timezones

• mbrubeck: For people in the US and Canada, this meeting (the "late" one) will be one hour earlier starting next month (4pm PST instead of 5pm PDT).
• jack: Europeans, too. Though still the middle of the night.