1

Meeting 2013 08 05

Josh Matthews edited this page 2013-08-05 18:00:09 -07:00

Table of Contents

• Servo Meeting 2013-08-05
• Agenda
• Attending
• quadtree tile memory issues
• binding conversion help
• landing parallel layout
• system libraries for android
• 0.1 criteria
• Benchmarks
• Acid 1

Servo Meeting 2013-08-05

Agenda

• quadtree memory issues
• request for help on binding conversion
• landing parallel layout work
• 0.1 release criteria
• benchmarks
• acid1

Attending

• kmc, jdm, jack, seo, ryan, dherman, eatkinson, tikue, eschweic, brson, pcwalton

quadtree tile memory issues

• jack: samsung brought this up and we were wondering how it's supposed to work
• eston: for the most part tiles are being deleted correctly when i use it, monitoring with the opengl profiler. what i do to delete tiles is a method that checks if they are far away from the tile that was just added. it's not the best heuristic in the world. there weren't very many details about how they were checking. the other issue is that it does save tiles until a certain memory limit. so maybe that limit is never getting reached.
• jack; do you know what the memory limit is?
• eston: i'm not sure what hte units are, but it is 1M pixels or 10M pixels i think.
• jack: ryan, seo, do you have a test page you were observing this with or know what the memory usage was?
• seo: memory increase happens on any page. like when you zoom in and zoom out
• jack: eston: we don't evict until we hit hte limit, correct?
• eston: when you zoom back out the tiles will still be there so we can just rerender them.
• seo: we'll summarize our findings and send an email

binding conversion help

• jdm: i have a PR open right now that starts converting text nodes and a few html elemnts to use generated bindings. the last commit (converting <a> (HTMLAnchorElement)) shows what other elements will require. it's a good model and it's really easy to break up into one element at a time, so it can be easily parallelized. i would like people to start helping because there are a lot of elements. i copied the idl files from moz-central (dom/webidl).
• jack: it would probably be nice for each of us to do some. this is the stuff like DListElement right?
• jdm: yes

landing parallel layout

• pcwalton: i'd rather have correct layout than fast layout. we had problems in the past where intern code didn't last long. if we integrate early it should be better.
• jack: what about the flag, why is the flag needed?
• pcwalton: i'm worried that it will be too slow.
• eatkinson: you probably won't notice the speed because CSS selector matching takes so long
• brson: we have two options, even thought it's parallel code can we still do it sequentially?
• pcwalton: even if we knew we were going to ship parallel layout we need a control feature to compare against.
• brson: i feel like we want to preserve this flexibility
• eatkinson: ok, i'll try and get it landed this week.

system libraries for android

• samsung: currently servo is relying on some system libraires like freeytpe and fontconfig. we'd like to wrap that in a servo
• jack: i have no objection
• pcwalton: what does webkit on android use?
• seo: we considered two laternatives, including binary form somewehre, the second way is to include the source in the repo.
• pcwalton: it may be that android doesn't need fontconfig
• brson: it may be that hte NDK toolchain doesn't have the freetype headers
• jdm points to http://en.wikibooks.org/wiki/OpenGL_Programming/Installation/Android#FreeType - "If you need FreeType (a library to render fonts), you'll need to cross-compile it. Note: The Android system uses FreeType but internally it doesn't expose it to native apps."
• samsung: we'll let you know the address of our repo. please take a look.
• jack: so it sounds like everybody has to cross-compile freetype. we're already bundling several libraries so building some more. i'm happy if you add more submodules for freetype and fontconfig, and we'll linke those into the build system.

0.1 criteria

• jack: sent out mail last week: https://groups.google.com/forum/#!topic/mozilla.dev.servo/4yPk-veDr7U
• kmc: wrt security, should we think about replacing stb-image before claiming it to be usable?
• pcwalton: there are many libraries required to replace it with. libpng, libjpegturbo.
• kmc: not trivial but I'd rather 0.1 only supports a few but is theoretically secure instead of supporting lots and being known secure
• pcwalton: how much is security a milestone?
• jdm: also using a year-old spidermonkey
• pcwalton: don't think anybody will be using servo
• kmc: matter of principle. part of the point is for servo to be secure
• pcwalton: when do we focus on security, add sandboxing, etc?
• kmc: can't claim to be secure as long as we have all this unsafe code, segfaults, etc.
• pcwalton: concerned about segfaults
• jack: DLBI added, agreement that embedding important, android important. anything else? what about benchmarks?
• sanxyin: should use netsurfcss in 0.1?
• pcwalton: not happy with it but wouldn't block
• brson: agree. it's functionally complete
• brson: will give a bad impression about perf
• jack: 0.2 will have a huge jump in perf though
• kmc: major thing there is selector matching?
• jack: that is like all the work though
• kmc: perf is so bad that we don't need parallel matching?
• pcwalton: yes
• kmc: do we need stack switching on 64-bit?
• pcwalton: no. patches are not in yet
• jack: not going to block on netsurfcss
• jack: back to benchmarks... purpose would be to get a baseline from which to show improvements
• pcwalton: that's why we need dlbi. otherwise numbers will be bad
• jack: things we're interested in: memory use (important for mobile) - calculating memory after layout would be good.
• jack: posted a message from blink-dev about cpu use in different areas on the main thread. might be nice to come up with similar test.
• brson: do we need some sort of automated dashboard, isservofastyet, so we can start capturing these over time?
• jdm: could we reuse the same things used for rust?
• brson: I think that's just matplotlib.
• pcwalton: it would be nice to use the profiler, but it's not event-based. it would be better to do something based on events like page loaded, restyled, etc. instead of time.
• jack: we could have the profiler spit out a json file as well as an image after page load.
• ... notes missing ...
• jack: do we want any other projects? jdm's dom wrapper work? (something else)
• brson: no, we don't need to be too ambitious. is there any kind of automation?
• jack: there's some kind of make target?
• brson: let's make sure it's hands-off, we're not really focused on releases.

Benchmarks

• jack: got feedback privately from brendan to focus on parallelism rather than single-threaded cases
• jack: for general cases of dom manipulation, layout, selector matching, we should probably focus on ...
• jack: when in portland, talked about jdm's testcase of setting style property and calling getclientrect in a tight loop (microbenchmark). pushback saying we should look at macrobenchmarks instead. went looking for benchmarks, most seem to focus on JS performance disappointingly.
• brson: we've talked about instagram (?). cross-origin iframes.
• pcwalton: servo won't win on image decoding. stb-image is slow.
• jack: imaging synthetic benchmark: iframes doing work (calculating 1000th fib number in stupid way)
• pcwalton: we should win on that.
• jack: don't want to create stuff that's stupid, but it seems like w'ell need to create our own benchmarks and want to stimulate thought about what those should look like.
• jack: resizing with lots of iframes should be a good one, since all iframes should reflow in parallel unlike other browsers. we'd also like to not totally suck if there's one iframe vs several hundred.
• jack: seems like we should have benchmarks for selector matching too.
• pcwalton: I'd like to see a general page like wikipedia; timeline of where we are relative to gecko and webkit, don't have infra to do that. that's where we'll see meaningful data - what to work on, what to do to close the gap.
• jack: run single vs. parallel layout on 100 wikipedia pages?
• pcwalton: dom microbenchmarks ...
• jack: what infra do we need?
• pcwalton: take existing profiling stuff, make timeline view. event monitoring... timeline view like in firefox and chrome devtools.
• jack: no way to profile across function calls right now, since it takes callback.
• pcwalton: take existing profiler, augment so instead print out a log of time T event E. write script to turn that into timeline display, then can compare to gecko.
• jack: ok, sounds good.

Acid 1

• jack: we're close. all boxes showing, bottom ones too low.
• samsung: doesn't that need margin-collapse?
• jack: maybe. that might be the issue we're seeing.
• jack: trhee problems: borders on bar maid not there - asymmetric borders. boxes too far down, and paragraph not reading inline style. then radio button, too.
• pcwalton: don't need form widgets to pass.
• jack: bang and whimper shouldn't be on top of each other. small things, looking good.
• eatkinson: I don't think those borders should collapse.
• jack: we have clear now; not necessary for acid1 but still awesome.
• samsung: floating elements should be painted over background, but currently painted behind. building display list should happen in stages.
• pcwalton: no, should be a way to place items at different positions in display list. multiple traversals slower, but we can place items in list and string them together.
• eatkinson: things lower in tree go on top (not always true with floats)
• samsung: currently in tree order, but not true for floating elements.
• jack: seo, can you file a bug?
• seo: sure.