Meeting 2013 06 03
Simon Sapin edited this page Jun 4, 2013
·
3 revisions
Slides Intern update
azita, seth, tikue, eatkinson, pcwalton, brson, jdm, bz
- brson: We did a review of these last week. No change since.
- azita: Due wednesday.
- 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?
- 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