-
Notifications
You must be signed in to change notification settings - Fork 0
Meeting 2013 06 10
- hiring update
- projects
bz, jack, pcwalton, azita, eatkinson, simonsapin, brson
azita: keegan starts july 1
jack: need to figure out what projects will be in the short term
jack: maybe we can start with CSS stuff, overlaps with Samsung's work
pcwalton: nasty crash bug in netsurfcss on css files longer than 30 lines
jack: have you looked at samsung's CSS code?
simon: no. i started reading the [something]. there are many optimization [tables] I need to know about
simon: based on the email description i don't know if it's worth looking into if we dont' care about it at all
bz: the way this code work is it is a selector matching library that doesn't know what the DOM looks like. you pass it a void* and then calls a function that. pass function for each class
brson: you could imagine a formulation with typeclasses that would be static
bz: question is whether it's easier to do that or rewrite it from scratch. selector matching isn't all that difficult. all the hard parts are making it fast and [something]
bz: the only hard part is descendant combinators, which this doesn't do. if you have a selector like #foo #bar #baz how do you go about matching that.
pcwalton: part of the upshot here is the rust-css approach is not worth it. we should fold this into servo. the reason for rust-css existance is to insulate us from a css library that we wouldn't want in the long term
bz: one other note is that we want to be able to evolve our CSS implementation. we're not a good consumer for off-the-shelf CSS library because we're in the business of changing CSS.
pcwalton: that library is not threadsafe and I'm going to hack it today
pcwalton: maybe parsing
bz: parsing may be a seperate library but it's still something we have to maintain
pcwalton: noone really wants selector matching but browser
bz: not necessarily true. queryselector and queryselectorall [something]
bz: may not want to use the same matching algorithm as the rendering engine. they do in webkit and gecko for convenience, but they are solving a different problem
bz: they are different problems that might want different approaches. i can see a desire to have a selector matching library for that
pcwalton: if somebody wants rust-css they can have it. we won't maintain it
bz: my basic bias is if it's not in the browser
brson: want things to be module. can't always make this decision to fold things into servo
pcwalton: 'slippery slope' fallacy. we won't always do this
pcwalton: i don't see us e.g. folding skia into servo any time soon, whereas CSS selector matching
brson: it's more about maintainability
pcwalton: we can keep it a seperate crate
simon: [?]
jack: should make it standalone as possible without sacrificing performance. should revisit when we have concrcete code
pcwalton: there's a question about whether to put it in a seperate crate jack: I think so
pcwalton: make it another crate like script, net, util, etc. build times will be better as a seperate crate
seth: the difference is that we're giving up on letting others use it in other projects. it's still seperate?
pcwalton: yes. it's a lot easier to keep things in sync if it's not a submodule. you can modify crates in servo much more easily
seth: it's a git workflow issue. hope that's not the only reason. there are potentiolaly ways around that, e.g. we write a tool on top of github
pcwalton: realistically the diff crates in servo are not there for reuse but to get better build times. everything in servo is kind of one thing. it might be possible to pull out the dom crate and use it independently.
seth: agree wrt benefits of modularity. if servo is to be a research platform would be nice to minimize interface between components
pcwalton: kind of need selector matching tied into the dom to some degree
simon: if we want people to use the code we need stable api
pcwalton: can't promise that
jack: i don't think anybody would suggest that yet
jack: there was talk on string internment friday. is anybody working on it?
pcwalton: we don't know what we're going to do yet
jack: we're going to have some more discussions on what we're gonig to do. we can ask samsung to participate in that
jack: everyone wants to work on layout. how do we split this up?
pcwalton: we need ref tests. need absolute positioning
bz: what are the ref tests for?
pcwalton: regressions
bz: 'all the text disappears' is pretty straightforward. you just [something]
bz: the thing with reftests is it's good at testing particular things. assuming correct functioning of the rest of the system you can come up with a test that will catch it
bz: you don't need positioning per se, need to isolate the thing you're testing
bz: that help?
brson: no. how to bulid a test harness
bz: gecko has two pages, loads them into frames, draws to canvas. there are some provisions for allowing slop because of aliasing
pcwalton: can resurrect the PNG compositor
bz: in the end what it comes down to
brson: still need a way to establish baseline and it seems like abs positioning is the general strategy there? ...
bz: if you want to test underline draws something, you do one with underline and one without and assert they are different. so reftest is not a good tool for pixel
brson: what other kinds of asserts? assert_eq, assert_not_eq. any others?
bz: yeah that's basically it, also loading does not crash the browser
brson: can we can we get far without absolute positioning?
bz: yes
brson: so we just need to create something that can create the two bitmaps
brson: are the reftests portable?
bz: modulo -moz properties, it should be portable
(missed)
jack: that's how we tested ghostscript. we had a fuzzy matcher. if you changed the text rendering we had a tool to force-pass everything. had a repo of valid bitmaps. mostly for regression testing
bz: so there's that approach. has that problem. needs fuzzy matching because of antialising changes etc.
bz: other than that the only other stuff I know is manual. we don't have the manual
pcwalton: it's ok for now
bz: when I say manual, MS e.g. has people who spend all their time comparing test cases visually
pcwalton: our infrastructure is really busted right now. everybody is on my branch because the bots are busted
jack: ill get that fixed
bz: other approach is to set up physical setup with camera and comparing to known bitmaps, which (sucks)
pcwalton: we have a hfr camera for b2g. would like to do that early because getting pan/zoom to work is not that hard but we need to not regress it.
bz: valid, but a lot of set up
seth: webkit had another type of test, serialization of the render tree.
bz: gecko used to have those. it's even more painful since every time you change the representation you need to update the tests
jack: what if you don't store it that way? parse this page and check that some property exists in a node
bz: a lot of that can be done in JS. we do this with mochitest
seth: at qualcomm we ran a tree-diff. kind of nice because it shows you what has changed
bz: going back to netscape render-tree dumper. issues: 1) change data structures needs to regenerate tests, 2) need to update serializers
pcwalton: have #[deriving(Serialize)]
bz: there are some flags that have different values but don't affect rendering. sometimes that's ok. e.g. gecko has a flag for a cacheline cursor which you don't care about. if you have timing differences this value can change
seth: a bummer for #[deriving(Serialize)]. you would want to specify that some fields don't matter
bz: not insurmountable difficulties
pcwalton: lets get ref tests up. resurrect the png compositor
jack: if you do that you're going to stomp on my work. easiest path is get GPU rendering. in compositor have a flag to spit out PNG of composited tiles. i asked before whether we wanted a pluggable compositor and we decided to do all GPU
pcwalton: since then i split out compositor from windowing.
jack: so composite and write out the window texture
pcwalton: shutting down the window would be writing out the image. continue
bz: w3c is adding reftest to the specs so we can importan tthose
brson: who's going to do this?
(missed)
pcwalton: i can start on this after i sort out the wikipedia crash
jack: last thing. I'd like to figure out at what point we can have multiple people on this area and who's going to get us there
pcwalton: that was true before we had the box model. now we do. it's missing things like height but once that's done it kind of branches out to various areas. i sugest coordinating with people about what you are going to do. I don't think it's the case that only one person can work on layout
jack: are your changes landed or in the queue
seth: I think everything i've submitted against serve should be ignored because patrick's branch is so far ahead
jack: but all your work is in some tree that people can get out
seth: everything that's going to be used, yes
pcwalton: I think erick's stuff duplicates it and is merged into my branch
jack: so what are you guys going to be working on now so we can prevent that happening again?
seth: that's one reason I'm working here. sounds like i can work on more layout stuff now. in short-term this week i'll work on non-layout stuff to avoid the issue
simon: currently there is work in gecko to add (?) which implies all layout to logical coordinates instead of physical. does it may sense to (?).
jack: this is for retina displays where you have logical coords that are pixel-doubled?
simon: no, this is about using (?)
seth: is caitlyn working on that. I've seen her mentioning it in IRC
simon: using such logical coordinates ... switching to logical coordinates after the fact ...
bz: someone had gecko patches for this. worth looking at the terminology they settled on.
simon: should we switch right now or don't care?
jack: is this block direction stuff added in CSS 3, 4?
bz: 3. supported by everybody except gecko and the web
jack: i'd say to add it soon since we're targeting modern standards. by the time servo ships there will be CSS 4 with more stuff. should get it out of the way while it's easy
simon: pasted a link
http://dev.w3.org/csswg/css-writing-modes/
jack: font rendering code has to take advantage of some of this
jack: does anyone know what caitlyn is working on? is she coordinating with someone?
seth: she mentioned an interest but beyond that Idk her status
jack: i'll ping her
jack: assuming I get GPU rendering done what should I do next?
brson: ref tests
pcwalton: there are a bunch of things related to COWDOM. I'd like to get us off glut. it's horrendous
jack: that's a pretty small project
pcwalton: switch to sdl
brson: sdl makes pinch-to-zoom easier?
pcwalton: idk. or something. if i told you the stuff we're doing to make the glut event loop work with messages you would cry
jack: glfw?
pcwalton: doesn't work on OS X 10.7 but I can upgrade
pcwalton: none of this is going to ship. equiv of netscape viewer
jack: reason for glfw is there are nice rust bindings. assume that's the same as sdl?
pcwalton: yes