Workweek roadmap

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.