Servo workweek notes 2014-06-02

2014-06-02 Roadmap review

https://github.com/mozilla/servo/wiki/Roadmap

jack: Manish making good progress on XMLHttpRequest
jack: nobody working on cross-language inlining
pcwalton: luqman is. nearly done
jack: where are we with spidermonkey upgrade
jdm: works. passes tests. needs more correctness
jack: more correct?
jdm: way we're dealing with handles isn't the best
jack: slow?
jdm: not unreasonably. we don't get same advantages as gecko because inlining
jack: C wrappers not inlined?
jdm: yes
jack: cross-language inlining should make us fast
jdm: will inline C wrappers?
jack: yes
brson: if you decide to package clang, let's just do it in rust - we need it too
zwarich: should be able to take ir from clang w/o debug info, will work with llvm of similar version
zwarich: debuginfo representation tends to change
jack: brson, is there a bug for building clang with rust?
brson: i'll check
simon: If we use pre-compiled Rust binaries, will that save everyone from having to build Clang themselves?
jack: Yes, then all the Clang libraries would be included in the pre-compiled Rust download.
jack: hidpi mode? finished?
mbrubeck: think it's finished. don't query android for screen density. that's a glut thing to fix
mbrubeck: putting small android things on hold until it works at all

(banter)

jack: have scrolling, pinch/zoom on android on the roadmap. should be seperate
mbrubeck: We should have "Android buildbot support" and "basic functionality / passing tests on Android" higher on the roadmap.
bjz: how's glut working for you guys?
jack: we make sure it compiles
bjz: been writing sdl2 bindings
brson: new ones?
bjz: yes
jack: We've talked about moving all of Servo to another thing. EFL and SDL are leading contenders.
jack: vertical writing modes, bidi
simon: these are independent of each other; both have a lot to do in layout
jack: pagination is another layout feature.

Embedding

jack: embedding zmike has been doing
jdm: servo runs in chrome shell
brson: is that already landed?
jdm: Yes. You have to download the Chromium code separately.
jack: could pull in chrome shell as dep, but not build by default
pcwalton: It would be nice to have a make rule out of the box, as an option. A lot easier for people to play with it. We could ditch our current GLFW/GLUT shell.
pcwalton: like webkit minibrowser. current shell missing things. could add features or use existing chrome shell
gw: what do we do on android
jack: Does anyone here have this running?
jdm: yes
jack: Let's go and stare over jdm's shoulder.

[everyone stares]

pcwalton: should use chrome shell only, abandon our shell
brson: agree. dogfooding
bjz: would be nice to get away from games libraries
pcwalton: Is there a port of CEF to Android?
jack: That's a zmike question.
pcwalton: next step is to use the full chrome shell with url bar
pcwalton: then sdl v.s glfw goes away

(banter)

HTML parsing

jack: html parser on keegans plate. going well. gw wants to use parser to parse w3c style reftest format. they use link tags to tell you where the ref html is. good way to flex new html parser.
kmc: plan to have generic tree building api and simple static dom for those without their own. should be straightforward to pull out link tags
pcwalton: question about whether we want this to be in rust proper
kmc: have html lib now but it's just escaping. this is going to be a big, prod-quality lib, may not want in tree
simon: not sure about moving libs like this (encoding, url) into rust repo. means any change becomes tied to rust
jack: By the way, brson, super kudos on the breaking changes log. I just kept it open in a window while going through errors in the last rust upgrade, and was able to find almost all of them instantly.
brson: How long did this one take?
jack: 2 days of not-too-intensive work.
brson: And how long had it been since the last upgrade?
jack: About a month.
brson: Nice! (discussion of transmute-related changes in latest rust upgrade)
jack: after rust upgrades land, i'll rebase 32-bit changes. should make the 32-bit android build actually correct
jack: incremental layout. biggest thing on roadmap nobody is working on
pcwalton: I can
jack: early you said 'after this rust stuff', which i took to mean the 1.0 release
pcwalton: no, unboxed closures
jack: gw had concerns incremental layout would interact with cow dom
gw: not sure. ideas i had seemed like there would be an impact, but not sure
jack: we can discuss later. webgl remove from roadmap. bjz was going to do it but not. we'll add your actual project, SIMD layout
jack: w3c platform tests working. should probably have discussion about next steps. (missed)
jdm: when possible. haven't had too many cases where we needed to decide

Q3

jack: q3 goals broad right now. now that dom is in good shape, idea is to implement DOM features
simon: (can't hear)
jack: gw was talking about using parser to find reftests for w3c tests
pcwalton: random bugs in layout. bug squashing on wikipedia is valuable.
bruno: wikipedia is primary target?
pcwalton: it's nice because it has a lot of text and is very parallelizable
pcwalton: alot of new sites like CNN are currently very paralellizable - we get 2-3x speedups
pcwalton: not far from rendering CNN correctly. inline float bug gw noticed
gw: took that one and 3-4 float layout reftests, all showed minor bugs. if we can get in some of those reftests and solve them ...
pcwalton: not sure h (missed)
gw: put in 3-4 css working group and all failed
pcwalton: because floats?
gw: the tests i put in were float layout issues, yes.
jack: Other things in the stretch items... CSSOM which zwarich was interested in?
zwarich: wouldn't say i'm 'interested' but lars told me to work on it
jack: EFL or SDL might happen if someone has time for it. xvfb priority depends on whether we move to Travis CI (from releng hardware which won't do headless testing)
jack: relenge won't upgrade certain libraries. only way to work around bugs is to switch ci
zwarich: gpu's don't have limitations about rendering without software stack. should be possible to render headless
jack: on linux you have to have X display pointer. can't do it without X
kmc: can do it with EGL, but drivers not great
jack: think xvfb will work but compositor has bug. should get martin to work on this; may be similar to the nvidia bugs he is working on.

(banter)

jack: visualization is also on here. specifically a demo. have in mind something we can use to visually show perf numbers.
jack: idea: color overlay of stuff rendered on screen for what processor was used. rainbow pages mean parallelism. could render serially and parallel. for each node in flow tree could show ...
bruno: worked on similar thing for webkit. for every rectangle layer there was a yellow square around with fps measurement.
jack: if you are interested in working on that, great
jack: those are stretch q2. usually we don't work on demos until last minute, but would be good to have something

(banter)

kmc: we were talking about making a blog post about JS. with the custom lint would make a good blog post. jdm and i will work on that
bruno: would be nice to have some sort of 'planet'
jack: these tend to get on the mozilla research blog. don't have a lot of people blogging about servo. are you going to write a servo blog post?
bruno: maybe ...
jack: i'll make a planet
mbrubeck: http://viewvc.svn.mozilla.org/vc/projects/planet/branches/ has the existing sub-planets managed by IT
bruno: e.g. manish has to do some reporting, would be nice for him to blog
jack: has he been doing blog posts?
jdm: no. just status updates

Q3

jack: flexbox. seems aggressive considering writing modes and pagination won't be finished. probably push to Q4 (along with the rest of the browser)
pcwalton: we've hit goals on paper, but it's kinda buggy. lots of remaining work just fixing bugs. hard to plan
jack: We need crashtests; we need real-world test cases in our test suite.
pcwalton: It's not just regressions; it also just finishing edge cases and bugs in the stuff we've supposedly implemented.
mbrubeck: At some point we'll need QA.
jack: CSS and DOM we have "many features per tests". should think about what those are going to be
jdm: need to turn on automatic web platform tests
jack: just blocked on releng - when we switch to travis, it should Just Work.
simon: are we going to run an x server on travis?
jack: have to do something. releng won't upgrade machines or install fonts. have to move. if can't use travis ci, then we're going to have to do it in ec2 ourselves, put mac minis under somebody's desk
jack: other Q3: TLS. Removed NSS and NSPR from build since they were hard to maintain and didn't support 32-bit
jdm: don't feel it's necessary work for Q3
brson: Rust needs this too. could have some kind of cross-project effort here

(banter)

kmc: high profile TLS vuln. would be cool to have pure rust TLS implementation.
jack: would be cool if you know somebody
kmc: tony arcieri

(discussion about Rust-based TLS and failings of OpenSSL and GnuTLS)

jack: caching, canvas, web animations. canvas, web animations don't seem super important. caching should get something done. maybe string interning too. allocate way too much stuff, every time through layout. also have image cache task and resource task that have need been edited since before i joined. that code is ridiculously bad and old.
simon: do we need to figure out string representation for string interning, or are they independent?
kmc: I think they're not that closely coupled, but might as well decide. I'm in favor of utf8 everywhere. Spidermonkey utf8?
jack: do we know if they are thinking about doing that?
kmc: spidermonkey folk have weighed in on that subject and v8 does it
pcwalton: anything but ucs2
kmc: if we have utf8 strings it won't be expensive to give them to spidermonkey. in favor of using utf8 and using hacks to get ucs2 semantics where necessary
jack: hopefully it's fast
simon: the problem is indexing into JS strings
kmc: have ideas, can discuss later
jack: main question: does anybody have things not on list but should be?
jack: should talk about CSS and DOM features to prioritize
gw: work out priority of android as well? should it become a first-class citizen?
jack: should. android been underprioritized because we don't test there much. if servo goes to production main platform will be mobile.
mbrubeck: mobile, yes, but is it more likely to be used in android apps, b2servo, etc? android is a good place to be, but is that the long-term goal?
pcwalton: mobile browser easier than b2servo
jack: have intern in june working on mobile power measurement. all tools for that are on android
mbrubeck: main android breakage is stupid rust linker minor bugs
jack: lots of compiler toolchain issues. rust team not prioritizing android
mbrubeck: once the automation is up and passing, that will give us most of what we need to keep it going
jack: once it's up it will start blocking rust upgrades, and we may prefer upgrading to working android
mbrubeck: also mean a third plattform that might break; everybody will need to learn to test android
kmc: hopefully we get a try branch
mbrubeck: but to fix you really need it running locally
jack: should investigate compressed DOM representation, tiling, etc. soon so we don't go too far into dom without thinking about memory efficiency
jack: anything else
brson: At one point we thought graphics web APIs were very high-priority for demo purposes. Have we deprioritized those?
jack: We have done a little work on canvas. If we're going to be doing this big layer refactoring, it's not clear we should be doing a lot of graphics stuff.
jdm: Also, people say it's not an interesting problem to solve.
brson: But in Servo, there are some architecural diffuculties.
jack: We also had questions about replacing Azure with a thinner layer for disk/memory reasons. We talked to Bas about our options. He has some ideas already about what he wants to build as a new browser-focused graphics API from scratch. But that would be a multi-year, multi-person project for Gecko. Servo, on the other hand, only draws four things (boxes, lines, images, and text). So we could start building the API with support for just those four things, and add more as we go along. That would let us get rid of Azure and replace it with something more direct that just generates OpenGL calls.
gw: if we could turn on opengles3, we could get benefits of some of the es3 only features, like the sync primitives.
jack: bas' stuff wasn't super concrete, but obviously had lots of ideas in mind
mbrubeck: would limit to android >=4.3 -jack: I think that's fine. We need ES3. Technically we target ES2 now but I think some random non-ES2 stuff sometimes sneaks in.
kmc: is webgl based on es2 or 3?
jack: uses what we think is es3 (opengl 4.1). webgl2 will get multiple render targets, geometry shaders. could be useful for servo.
gw: for corners, e.g.
jack: when we talk to roc, dbaron, bz, they're not interested in the graphics stuff and always talk about the other things on the list.
jack: other reason I like this new API idea is that browsers use existing game-oriented APIs differently - using multiple contexts exposes drivers bugs. could create new API that's good for multi-thread usage.
brson: we are not just a research project - we need other things - like flash!
jack: Shumway?
jack: it's worth adding flash (not Adobe), but WebAnimation and canvas are not necessary for that. (discussion about Travis CI)

ACID3 task replacement

jack: ACID 3 was Q2. decided not to do it, but need to replace it with a new milestone. only have vague ideas
kmc: getting a real webapp working
jack: will have XHR
Manishearth: We need forms (input widgets, etc) for most webapps to work
jack: google docs is really hard, uses a lot of features. somebody suggested etherpad
bjz: etherpad would be good for dogfooding seeing as we use it in the meetings.
pcwalton: does it use contenteditable?
zwarich: could make readonly features work
pcwalton: uses Ace, which is huge
zwarich: find the popular apps for 2003, etc.
jack: might solve our wikipedia issues - take random subset of wikipedia pages and make sure they are fully operational
brson: doesn't give you the kind of PR bump that ACID does
jack: idea is to make new test suite that shows servo in good light, and test other browsers against it as well. it would be nice if we looked good in comparison.
jack: any ideas
bruno: dom spec
jack: what are we missing there?
bruno: queryselector, some Css properties, don't recall what else
jack: is XHR in ACID 3?
jdm: (shrugs)
mbrubeck: there's ringmark, but probably more than we want to take on.
jack: could find properties on css usestats that aren't being tested by acid1/acid2. empirical method.
bruno: one of the things here is instrumenting servo, like the rectangles we talked about earlier.
pcwalton: we have profiling infrastructure. it's not good. could do something like the chromium timeline, exporting the same format and loading into chrome devtools
mbrubeck: or firefox remote devtools api. we could bug the people writing them to fix things.
pcwalton: does it have a timeline?
mbrubeck: yes
jack: is that for firefox for android?
mbrubeck: and b2g
jack: we can't host that stuff because of XPCOM, but we can probably interoperate
mbrubeck: it has a wire protocol
mbrubeck: anybody know anything about the css maze solver test
pcwalton: we can do absolute now. probably not hard to be faster than other browsers. ff is bad on it, because overflow calc. servo doesn't have overflow so it'll be faster!
pcwalton: think maze solver is good to work on. needs incremental reflow

(discussion of css maze solver)

pcwalton: I don't see a timeline like chromium's.
jdm: they've also got a wire protocol...
jack: not a lot of benchmarks that aren't JS - maze solver is nice because it's non-JS so we could potentially be faster. are there others that we could collect, make something like octane and call it a layout benchmark?
pcwalton: could make pages like the rainbow one, or lorem ipsum - bjz should have made a page with tons of text really good.
jack: is there a way of timing this in chromium?
jack: nice thing about octane is you visit the page and it tells you how fast you are. can we add content APIs to report performance?
pcwalton: hard in general since browsers break down layout into different stages, so difficult to compare. easy to game sometimes, eg. webkit pushing onload earlier to win on benchmarks.