Meeting 2013 09 16

Servo Meeting 2013-09-16

Agenda

• Profiler
• Harfbuzz
• Flow tree construction
• Android testing
• Demo
• Korea work week agenda

Attending

• Mozilla: pcwalton, azita, brson, kmc, lbergstrom, jdm, jack
• Samsung: ryan, seo, etc.

Action Items

• pcwalton ask Jonathan Kew about short-circuiting harfbuzz for simple text
• samsung send office address so we can book hotels

Profiler

• ryan: q about profiler. measuring layout. text_shape calls harfbuzz. uses a channel to collect timestamp. surprised that the profiling itself takes a lot of time. wondering of there's a way to disable the profiler. the -p option gives the profiling timestamps but without the option it still performs the profiling. is there a way to disable profiling if we don't give the option.
• pcwalton: yes, we should not be doing anything if profiling is off. sounds like a bug
• ryan: is there much overhead to the channel sends?
• pcwalton: atomic compare and swap and a context switch
• kmc: isn't that send_deferred?

Harfbuzz

• ryan: for each word it calls harfbuzz. we looked at webkit and webkit classifies words as simple text or complex text. for simple text it goes straight to skia.
• pcwalton: I don't know what gecko does here. Probably worth talking to Jonathan Kew. He's an expert and can tell us if that's worth doing.

Flow tree construction

• sanxiyn: I know there was discussion of incremental flow tree construction last week. Did anything come of that?
• pcwalton: eric, lars and I discussed plan for incremental flow tree construction. lars, you had some minutes. can you send them to dev-servo?
• lars: I also have some pictures of eric's notes
• pcwalton: lars will send the notes. it will be a bottom up tree traversal with special stuff for keeping around old flows. should be straightforward. once we have that we should have incremental reflow.

Android testing

• sanxyin: filed an issue to enable testing on android. Any progress?
• brson: jack has been in contact with releng.
• jack: talking to release engineering. there hasn't been a lot of progress. we had a request from a couple weeks ago to upgrade bors and they just started working on that. hopefully that means we'll have some forward progress on that.
• sanxyin: aiui, rust should pass on android out of the box
• sanxyin: ?
• pcwalton: Rust's CI is not being handled by release engineering
• azita: we're going to discuss it but it won't happen soon
• https://github.com/mozilla/rust/issues/9120
• brson: we'll revisit this issue once 0.8 is out.

Demo

• jack: had workweek. worked on building a demo for mozilla summit in beginning of october. The demo consists of o couple of parts. The main two are linked failure - when an iframe fails we can show a failure page. Other is sandboxed iframes. Same-origin iframes can run in a seperate task. This allows us to run JS that never returns control back to the script task, so one iframe can avoid interferring with animation and such going on in other iframes. We're wrapping this up.
• jack: a samsung engineer expressed an interest in this, so I'm wondering what kind of things you want to get done while we're in korea, and what sort of demo's you are interested in
• ryan: demo we need to present at the end of October to our executives is to prove that execution time of servo is comparable to some part of webkit. i.e. overall perf is slower than webkit, but we want to find some smooth part that is faster than webkit.
• pcwalton: that's something that we'd like to do as well. i think that one simple thing would be to get the paniting faster since we can do parallel rendering of tiles. may be able to show an improvement over webkit there.
• pcwalton: once we have incremental flow tree construction and css is replaced with simon's implementation layout could be comparable.
• ryan: when we measured rendering performance webkit was faster. would like to find something layout that is faster.
• pcwalton: I think with incremental css and flow tree we'll be good, but we haven't pushed on this.
• jack: in the demo we have we're faster than webkit if there's ilooping javascript
• pcwalton: but in terms of throughput it's not much faster. the main gains are going to be in parallelism across blocks in layout, which we don't do. eric has patches.
• jack: seth was working on parallel shaping. did he get anywhere on that? we may be able to parallelize shaping and get lipsum working fast.
• sanxiyn: we discussed that but if we stop calling harfbuzz, parallelizing it won't be much win. we instrumented webkit code and browsed the web and harfbuzz is rarely called.
• pcwalton: most of the gains are going to be things like parallelizing across blocks and that's something that will require eric's stuff. i'm curious why we're slower than webkit at rendering though.
• ryan: when I measured perf of layout, servo was slower than webkit. can you think of any part that is comparable to webkit without paralleization.
• pcwalton: tree traversals, bubble widths, assign widths, assign heights. I'd imagine those are comparable, except for text shaping.
• jack: solving for heights, given that CSS selector matching is done
• jack: do we know how close eric's patch is?
• pcwalton: no
• jack: if we could get the text shaping fast path in and some form of parallel layout then we could get pretty good. need to try.
• pcwalton: css selector matching is still slow until we get the new version
• pcwalton: CPU rendering should help with rendering performance
• jack: do you have a demo planned? can we split up the work somehow?
• samsung: we were measuring the different parts of layout to try to find a part where servo is comparable to webkit. We were surprised that, for example, debug is enabled in default builds. Also, the profile channel issue.
• pcwalton: why is debugging on by default?
• jack: is debugging output taking more time than layout itself?
• pcwalton: not surprising - layout is small. And the debugging requires a check of the global crate map.
• jack: should we add a flag to turn it off?
• samsung: we know how to disable it. An option to disable debugging would be nice, but it's not urgent. It's useful to have it on by default, but just inconvenient when doing performance measurement.
• jack: demo is before the workweek in Korea. What would you like to work on while we are out there?
• samsung: no concrete plans. we are thinking about it.
• azita: We do not need an agenda now. Andreas Gal is planning to travel for the first part of the week. It would be good to have a high-level agenda to determine the best time for him to meet with everyone.
• samsung: we will discuss it.
• azita: I also sent mail earlier, so we can continue to discuss it.
• samsung: this week is Korean Thanksgiving holiday, so today is the last day of the work week. There will be some delay.
• samsung: Mr. (?) is on his holiday this week. When he comes back next week, they will attempt to fix the date and come up with a high-level agenda.
• azita: also, if we could get the address to the Samsung office so we can arrange hotels, that would help. We are assuming we can work in the Samsung office, is that acceptable?
• samsung: we will try to book the meeting rooms for the full week.
• azita: An address for the office and possibly a hotel recommendation would help us plan our travel.