Meeting 2014 06 30

Agenda

• ICE blocking SM upgrade (jdm/ms2ger)
• Compositor layer tree redesign (mrobinson)
• fate of the quadtree

ICE blocking SM

• jdm: It is fixed! The branch has been rebased (though it only works with a Rust from the past few days). It's now possible to keep pushing.
• jack: Need a rust upgrade?
• jdm: Yes, but the branch has all the changes required for it. I could take it on.
• jack: If you already have the hash, you should start making the snapshot now, because the OSX builder is only 50/50 on completing in 50 minutes. Best to have a little headstart on it.
• jdm: Will do after the meeting.

Compositor layer tree

• jack: Hopefully you've all seen Martin's post to dev-servo with the new design.
• mrobinson: Should have the first patch posted tomorrow, probably. I am rebasing it, and I need to check for regressions. It's just a first cut of the redesign with the things that have to be done all at once.
• jack: What is in the Compositor Data stuff?
• mrobinson: It is the data that CompositorLayer used to hold that was specific to servo and not rust-layers. Things may move around (some have already, like the ContainerLayer now has an origin). There is also still some duplication that I want to remove. Basically, all of the members of CompositorLayer are now CompositorData members.
• jack: CompositorLayer.rs? The bounds, pipeline, pagesize, quadtree, whether it's hidden, scroll events/policy...
• mrobinson: The quadtree is in rust-layers right now & the children are part of it too. But anything to do with scrolilng is in the CompositorData.
• pcwalton: Quadtree is still there, right?
• mr: I didn't want to touch it until I did this refactoring. Should be easy to replace it.
• pcwalton: Yeah, that was going to be my question. Sounds great! I wouldn't worry overly much about removing Rc and RefCell. They don't have that much of a perf. cost - I doubt you will be able to notice it at all. All of the pointer stitching will dominate the borrowflags check, etc.
• zwarich: Making a design that removes internal mutability is probably not worth the effort because we don't necessarily have a long-term design that removes all internal mutability.
• mrobinson: I added some - there's a lot of borrow_mut that didn't exist before, because CompositorLayer didn't set flags, but now it does, because it's part of ContainerLayer.

QuadTree removal

• pcwalton: It's too complicated for something that can work with just a list of tiles and two zoom levels.
• zwarich: You have a uniform grid; we don't need a more complicated spatial data structure. That's what WebKit does. For multiple zoome levels, it's pretty hard to have more than 2 because once you have more than that you start running out of memory. So it seems like a grid-per-level would be good for now and we probably won't need more than that.
• mrobinson: It'll be much easier to optimize without the generality of the QuadTree.
• jack: So you will remove that after this refactoring lands?
• mrobinson: Yes, it'll be a pretty easy next step.

32-bit

• jack: I'm working on it. Every monday is "rebase monday", and the rest of the week is whatever the roadblock is. I think we got all of the submodules updated; hopefully a PR today.
• larsberg: is there any build stuff we can do to make sure the work doesn't atrophy?
• jack: it would be nice to build 32 bit cross-compile and have travis test that. there's not really that much code change, so there's not too much risk of bitrot. one area is rust-geom due to inline assembly stuff, and rust-mozjs there's a flag for different implementations of some types between 32/64. if we test android, that should also test 32 bit. our previous testing didn't find the bug, so it's not clear that it will actually break if it gets broken. rust-mozjs doesn't change much - did it change in the new SM?
• jdm: shakes head
• jack: After you have the android snapshot, we can see how hard it is and maybe set up 32-bit

CMake

• SimonSapin: Did we decide on cmake?
• jack: It's one we're exploring, but there don't seem to be lots of others. I got stuck in one section, but since we have a volunteer with experience, maybe they can switch us over. I thought about trying to use Cargo, but it's missing cross-compiling and won't have it for a while, so that would be a huge regression. We may set up cargo files for some of the submodules, though. The other Cargo issue is you have to have a master checkout for it and then a snapshot for Servo, which means two builds of rustc, which is not so nice. It'll all work itself out eventually, though.

New intern!

• jack: Laleh is joining today. She will be looking at power metrics and power consumption on mobile devices. Say hi if you see her on IRC!
• azita: She's in SF?
• jack: Yes, in MTV today for the intern start, but in SF full-time. She will probably be near bjz.