Meeting 2013 05 06

Agenda

• floats / layout
• release engineering update
• graphics pipeline

Attending

azita, brson, jack, seth, pcwalton

Floats / Layout

• seth: talked to david and he recommended not to do what Gecko does.
• brson: what are we missing in Servo with respect to floats?
• seth: not sure yet
• seth: i heard in irc that since we dont' have basic box model stuff, it will be hard to do floats
• pcwalton: is that a prereq for floats?
• seth: the minimal implementation is just set up the data structures as if we had padding and margins working. from the point of view of testing, most of the rules involve margins heavily, so it would be nice to have something there.
• pcwalton: whatever order is fine. i've been refactoring some stuff around there which I'm trying to land part of today.
• seth: we don't need to deal with the rendering stuff, but I would like to have the numbers flowing through correctly
• pcwalton: that should come for free. the displaylist builder will lay them out like you ask.
• pcwalton: did you get a chance to look at flow vs. renderbox distinction that we have.
• pcwalton: there is a higher level flowtree structure. inside each flow are renderboxes. sometimes the renderboxes are manfiest values but in inline context, the renderboxes don't actually exist because they are determined by line breaks. in general, you can't rely on renderboxes being manifest values, you can only iterate over them. this is much simpler, but it's different from gecko and webkit because you have this two layer tree.
• seth: this seems like a strong argument for doing layout in one pass.
• pcwalton: why does it require one pass layout?
• seth: don't these things disappear after the iteration?
• pcwalton: they always exist, but they may not be encoded as a linked list of objects. the iterator takes the text boxes and the line breaks to get the list.
• seth: are you figuring out line breaks during iteration?
• pcwalton: no, those are pre-computed.
• jack: please document the layout architecture and your discussions in the wiki. i'll be doing the same for the graphics pipeline

release engineering update

• pcwalton: i'd like a rustdoc target for the makefile.
• jack: we have a bug filed by ben hearsum about releng integration. they want some stuff in the makefile for backing up the rust build. currently that's done by buildbot but they want it in the makefile
• jack: brian are you planning to do that?
• brian: I will
• jack: rustdoc build target as well?
• brian: Sure
• jack: How are rust's docs built and uploaded? bors?
• brian: not bors. make targets, scripts and buildbot uploads to s3

• jack: How hard is it to hook into the rust linter, to do a pass to see if traits are undocumented?
• patrick: We could add such a pass to rustc. Warnings if traits, types, methods, etc. aren't documented.
• jack: ok, I'll file a bug
• jack: we talked to ben on friday-ish, gave him ssh keys and list of committers. he should have something working this week. if all goes well we'll have servo compiled on the bots.
• seth: Is this how we get automoted testing going?
• jack: The endgame is to run bors just like rust.
• seth: Will we have multi-platform coverage?
• jack: Yes, we'll have linux, mac later. we'll look into android. It didn't sound like a problem to expand plattform coverage for releng.
• patrick: The blockers for porting to windows: fonts... There's a question about how 'good' it should be. Do we use d2d? This is down the road. It's good to wait because we can wait for angle d3d 10 to be released.
• patrick: d2d is all on GPU and it is the fastest rendering backend. it's d3d 10 only but the problem is that angle (opengl for d3d) only works for d3d 9.
• jack: skia doesn't need angle. it has direct support for d3d
• patrick: on chrome everything goes through gl, so i would be suprprised
• jack: i didn't investigate but it looked like it had a canvas for d3d
• patrick: so we have a choice between standardizing on opengl or implementing a native d3d rendering pipeline for rust-layers
• jack: it's not that complicated
• patrick: yes. will get more complicated over time with video, etc. it is pretty simple by design

graphics pipeline

• jack: skia gl working, ported to rust layers. not used in servo yet. now looking at how to integrate this into servo proper. been taking notes on the graphics pipeline, will put on wiki page
• jack: will put this into servo, do some benchmarking
• jack: q's for patrick. in render-layers there's a RenderLayer object that is a DisplayList and size. We're using an unsafe pointer to the RenderLayer. Why?
• patrick: Ideally it should be in an ARC, but there's some reason we can't do that currently. there's something mutable in it. we should make the displaylist Const so it can be in an ARC.
• patrick: Current architecture puts several render slaves in a task pool. They get tiles (render buffers) and render layer and each renders a portion in parallel. That's not necessary with GPU rendering so all this can probably be ripped out.
• jack: That's what I thought it was - a workaround.
• patrick: There's an annoying case where you don't know that the display list is complete because you don't know whether the images are loaded.
• jack: Can the DisplayList be freezable?
• patrick: Yes. We need Futures to behave like they are Const
• seth: Is the model that images are either done or not?
• brian: We haven't thought about it yet.
• patrick: Partially downloaded or partially decoded?
• seth: Both. They are partially decoded off the main thread.
• jack: Either way the DisplayList is going to have a partially filled buffer and we need to display it
• patrick: Yes. Instead of an all or none future it needs to be a buffer that slowly fills
• seth: It seems conceptually similar to animated images
• jack: We can think of something, but the core issue is that the display list needs to get better, not use unsafe pointers. Needs to be safe.
• jack: Other q: every time we go through a drawing cycle ... compositor has a draw command, we hand it a layer buffer, port to deliver the next buffer. That channel/port pair is created every time.
• brian: I'm not sure it's more efficient to reuse channel/ports
• patrick: More allocations?
• brian: ... yes, there may be an extra allocation to reuse.

• jack: Some code smells that need to be fixed

Last thing

• jack: I've gone through most of the gfx pipeline and want to describe what I found.
• jack: 3 parts: glut loop, compositor, render task
• jack: glut: we create a scene, surface set (front-back layer buffers), respond to draw .... calls 'render scene'
• jack: compositor exists to abstract these two messages: draw, begindraw. it seems wierd to me, may refactor
• jack: render task has render layer (bufer / size). ... gets render message, not sure where from, renders render layer, takes layer buffer set, calls RenderLayer, breaks