3

Meeting 2013 06 03

Simon Sapin edited this page 2013-06-04 07:54:49 -07:00

Table of Contents

• Servo Meeting 2013-06-03
• Agenda
• Attending
• Slides
• Updates
• Layout

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