Skip to content

Meeting 2013 07 01

Jump to bottom
Brian Anderson edited this page Jul 1, 2013 · 1 revision

Servo Meeting 2013-07-01

Agenda

  • welcome keegan!
  • gpu rendering

Attending

azita, brson, keegan, jack, eschweic, tikue

Keegan

  • jack: welcome keegan

GPU

  • jack: linux issue: on linux there's a failure in intel GL driver
  • jack: have to have a pointer to display. need to have one 'display' pointer and reuse it each time you create a GL context. unfortunately, GLUT, etc. all hide this.
  • jack: GLFW has an API to get the pointers. rewrote sample programs to use GLFW and a single display pointer
  • brson: good to use GLFW anyay
  • jack: yeah, nicer. bindings are maintained by bjz
  • jack: so build integration for GLFW and glfw.rs is done. working on making glfw_windowing. should be done tomorrow
  • simon: do we generally target the latest version or specific?
  • jack: in general, a pretty recent version. e.g. if we run into a bug that's fixed in rust we'll upgrade. if noone on serve has been adding any features to rust we'll let it sit for a while
  • jack: currently on a version from ~1 week ago. will probably upgrade to 0.7
  • simon: might we have problems with incompatible versions of glfw
  • jack: what I did in this case was used a version a couple vesrions back that is compatible with the rust we're using
  • brson: good point about using community packages in rust - they'll be on diff. versions
  • jack: for this I've forked glfw.rs and made our own branch with our config file changes

CPU rendering

  • jack: patrick has a pull for CPU rendering. will review today

  • jack: if anyone else is working on rendering/compositing you'll want to keep track of that pull and also follow what tim is doing since he's changing how these components talk to each other

  • tim: yes

  • eston: just got tiling working so tiles are only rendered when needed, but my version is a week - 2 out of date

  • jack: last rebase I did was pretty easy, so shouldn't be too bad

  • eston: seems like everyone's hacking on gfx

  • jack: working on ref tests. added png rendering. even with tiling we need to be able to render the full page

  • jack: erick working on floats. there's a pull open, so we have some preliminary

Scheduler update

brson: my i/o branch, that i am not working on personally (directing interns). trying to get that upstreamed so we can start porting servo. there is a bug on OS X with too many open file descriiptors. the last week or so i've been focused on the 0.7 release, which should be out the door tomorrow or wednesday. after that i'll start moving the scheduler in tree and start porting servo. we might have to have our own servo branch for a bit. we could end up with a temporary rust fork. probably won't happen this week, but probably this month.

jack: this won't have work stealing will it? brson: no. the scheduling is currently very naive.

jack: (discussion of niko's fork join and ffi patches.. neither will land in 0.7)

simon: right now i'm porting my parser to the new rust version and catching up with css syntax spec changes. after that

CSS

(missed)

  • jack: done with CSS parser? going to put it in the tree soon?
  • simon: don't know if it makes sense because we don't have selector matching.
  • brson: at least if it was in tree it would not bitrot
  • jack: yeah, if you want I can do the build integration, and that will force whoever ports servo to also port the CSS parser
  • simon: re: parsing. talked to dbaron about how to design parser. flat stream of tokens vs. rule tree of component values ala. syntax spec. with a flat stream you don't have to worry about nesting in the rest of the parser.
  • simon: idea is to take care of nesting at one point
  • jack: if we use a tree of component values does that make parallel parsing easier
  • simon: maybe. easier than with a flat list. dbaron thinks it may not be worth parallelising within single style sheet - pages already have many style sheets
  • jack: true up to a point but e.g. bootstrap.css isn't tiny
  • keegan: people also minify css into one d/l sometimes
  • jack: so everybody seemed idea about a restricted subset of CSS but I think those same types of annotation can be useful for parallel parsing since you can scan for them then divide and conquer
  • tim: can we use the restricted subset for all web content?
  • jack: restricted subset doesn't have absolute positioning
  • time: is it an outdated model
  • jack: no, but there are a lot of use cases where you don't need absolute positioning. a lot of wierd edge cases in layout have to do with abs. pos.
  • simon: and floats
  • jack: it's a cool idea
  • brson: where did this restricted CSS subset come from?
  • jack: mailing list. idea is like asm.js. have a restricted subset that's easy to layout
  • simon: could have a restricted subset of selectors and a restricted subsect of layout
  • tim: idea is that we'd still support both but for those that opt in we'd have a faster path?
  • jack: yes. this is what asm.js does - skips lots of work
  • simon: not sure this makes sense for CSS but we'll see
  • jack: yeah sounds interesting but really vague. i do think there's lot we can do with new annotations. if we can get the proper annotations added to the minifiers we can make the whole web parallel
Clone this wiki locally