Skip to content
Simon Sapin edited this page Jun 4, 2013 · 3 revisions

Servo Meeting 2013-06-03

Agenda

Slides Intern update

Attending

azita, seth, tikue, eatkinson, pcwalton, brson, jdm, bz

Slides

  • brson: We did a review of these last week. No change since.
  • azita: Due wednesday.

https://docs.google.com/a/mozilla.com/presentation/d/1_y6iFlwjKSCYO0cu9TM4wEb_syy2r_cDW0W7sdvqcPI/edit#slide=id.p

Updates

  • brson: Eatkinson did a bunch of layout work last week. about:mozilla almost renders correctly.
  • pcwalton: I can give an update on what we're doing.
  • pcwalton: Tim is doing some work on performance monitoring so we can collect stats, min, max, etc.
  • pcwalton: Regarding layout I've merged some of eatkinsons stuff. Some conflicts.
  • pcwalton: Some question about how to do borders, padding, margin on inline flows.
  • pcwalton: If we want to make about:mozilla perfect we need generated content.
  • pcwalton: Hit testing is merged so the next thing is to get simple navigation working.
  • pcwalton: We need to dive into why layout is so slow. We have ideas - that we're not caching text runs - but that alone may not explain all the issues. We need to be pressing on that to get that 'hammer layout' test down.
  • jdm: I left a bunch of comments in the bug w/ various hacky caches that get the performance down.
  • pcwalton: Did we change the test case to something that gecko doesn't optimize?
  • jdm: Not yet
  • pcwalton: We should have a test case that gecko actually does layout on
  • bz: But we also need to do caching.
  • pcwalton: Yeah, need to do work on both ends
  • pcwalton: Jack is working on GPU rendering and it partially works
  • brson: What's it going to take to upstream your branch? There's a lot of work out of tree
  • pcwalton: With Jack on vacation we'll need someone to review. jdm.
  • azita: Is Jack doing all the review?

Layout

  • bz: I have a related question. Going to spend some time on this. What should I do?
  • bz: Need to learn Rust. I don't have a good feel for where things are.
  • pcwalton: Learning Rust is a lot easier this summer than ever before! You may encounter internal compiler errors, but whatevs.
  • pcwalton: Tim has been working on some performance monitoring with SERVO_PROFILE environment variable. We need more probes.
  • pcwalton: Instruments and shark do work.
  • pcwalton: Most of the pipeline has been sketched out in stub form. Hit testing one of the last pieces. There's some major stuff that isn't implemented like invalidation.
  • bz: Is there any introduction to the code or just read the source?
  • pcwalton: Mostly just read the source. There is an overview on the wiki and a link to brian burg's presentation from last summer.
  • azita: Has anybody tried to watch the video from our presentation last week? It's supposed to be able to find by searching for the room we were in, ORLY
  • bz: Are we storinging style data off elements or render boxes.
  • pcwaton: Elements. Render boxes don't have 1:1 mapping to elements.
  • bz: That's something I should sort through because that's one of the things I'm interested in. Important for layout parallelism, shadow DOM, etc.
  • pcwalton: One of the things I've been talking with eatkinson is getting ad-hoc traversals out. Manually coded traversals bad for parallelism. We should use the traversal functions because we can switch them all over to parallel later.
  • bz: I'll look into this
  • seth: Reviewing eatkinsons' and my work. Both of us were implementing the same things. So I want to review what we're doing so we don't conflict.
  • seth: We've got a lot of people working on layout, so I'm wondering if it might be useful to spin up some other stuff.
  • pcwalton: Michael, do you know when Eston is arriving?
  • michael: today
  • pcwalton: ok, he's going to be working on tiling and scrolling
  • pcwalton: if you're interested in DOM stuff, navigation doesn't work at all. there's a lot that needs to happen, some design needed for having multiple pages in flight at the same time.
  • pcwalton: also don't know how we're going to deal with iframes. would be nice to be in seperate threads.
  • pcwalton: tied in to history, we don't have at all.
  • bz: session history or global?
  • pcwalton: what's the diff?
  • bz: session is back/forward, global is all urls ever
  • pcwalton: let's make it so there's no places-related jank ever. probably just avoid sync queries, make it all async.
  • bz: navigation, session history have a spec. it's not clear how compatible the spec is, and it's reverse-engineered spaghetti code. it's hard to say what it should like, but we know what it shouldn't. I can think about that some.
  • pcwalton: there are some fundamental questions like what db to use, leveldb, sqlite4?
  • bz: for global history, not session history
  • pcwalton: maybe global not worth implementing yet
  • seth: it's not that I don't want to do layout. my interest is more in high-level parallelism stuff. if getting involved in the box model is making me step on other people.
  • brson: Is this subsystem not big enough for multiple people to work on it yet?
  • eatkinson: It's intertwined
  • pcwalton: there's sort of an order you want to do things in. borders, padding, margin, inline, table
  • seth: it's kind of a linear progression
  • seth: once it gets a little further in it should get a lot easier to spread the work out. even to the extent I do still work on that, it'll be easier for me to be here in MV to work with eatkinson
  • seth: there's some various things I've been wanting to try out which we can't because the components aren't written in rust yet
  • pcwlaton: css
  • seth: mostly related to css
  • pcwalton: simon has it mostly done, except for selector matching
  • seth: is he going to do parallel matching first?
  • pcwalton: so, serial first
  • tkuehn: dzbarsky has done some of this (in gecko)
  • bz: it was before the bloom filter went in, so it needs some rework
  • pcwalton: we should be doing shaping in parallel. we can do this today because harfbuzz is threadsafe.
  • seth: that sounds like a good quick win
  • pcwalton: probably similar to the code to decode images in parallel.
  • seth: so I know we're never switching off of spidermonkey, in the near term. to what extent is spidermonkey pluggable. can we have the front-end in rust while retaining the jit, etc.?
  • bz: by frontend you mean parser?
  • seth: i mainly care about the parser
  • bz: the parser is pretty standalone. could conceivably be done in rust, i think
  • seth: that's one area we could get some win. previously had some good results up to 4 core with parallel js parsing
  • bz: we should talk to the spidermonkey folks because they are trying to be embeddable
  • pcwalton: people have written os kernels in rust
  • seth: it might be interesting to look at preparsing of javascript, similar to gecko does with css/html
  • pcwalton: to try to find the url?
  • seth: or to do simple abstract interpretation of resource loading stuff. there are some examples like .js where lots of resources are loaded from js.
  • pcwalton: the resource task needs some love. preparsing will need to spend some speculative requests to the resource task
  • seth: ideally we want to catch that stuff as it comes ofo the network
  • bz: in gecko it effectively prefetches the objects, not the data, but the data is in some ways the value part. ... -seth: we've discussed this that we need a streaming model <brian discusses scheduler - can't talk and transcribe at the same time>
  • seth: is the model - like in gecko we would create a bug in bugzilla and assign it to ourself
  • pcwalton: you can assign bugs to yourself
  • brson: we don't really make it part of our workflow though
  • jdm: it only works for people who are collaborators
  • pcwalton: we can make you a collaborator
  • seth: is there some command line program you are using?
  • pcwalton: ghi
  • seth: I notice the labels are very machine readable
  • brson: that's just graydon - he's very methodical