2

Meeting 2013 09 30

Seo Sanghyeon edited this page 2013-10-14 08:45:37 -07:00

Table of Contents

• Servo Meeting 2013-09-30
• Agenda
• Attending
• Patrick's layout work
• JS memory management issues
• summit demo crashes
• Memory leaks
• Work week
• Text shaping optimizations
• Iframe problems
• Android

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

Servo Meeting 2013-09-30

Agenda

• patrick's layout work
• JS memory management issues
• summit demo related crashes
• cpu rendering and layout speedup patch landing (pcwalton)
• gpu memory usage
• text shaping optimizations
• iframe problems
• servo android shell

Attending

• jdm, kmc, lbergstrom, brson, azita, metajack

Patrick's layout work

• jack: probably merge the speedups next week
• kmc: layout, rust upgrade, and cpu rendering all in the same branch. Might want to get cpu rendering for summit
• jack: 30% faster than gecko. We micro-optimized them and made Rust changes for code generation, which made serial layout faster than gecko for one specific benchmark. was that one of the things on your (Samsung) list of priorities for the next year?
• jack: hopefully we will land that before we come to Korea

JS memory management issues

• jack: Josh found out that we don't trace through proxies. The JS team thought it was a bad idea in general. The short-term fix is to patch SpiderMonkey to do so (they removed it). It will be upstreamed to them once they have their smart pointers stable. Long-term, we need a better plan because we are duplicating all of the code from SpiderMonkey that wraps these data structures. 1) could generate the SpiderMonkey code 2) could add support to Rust to inline C++ code in Rust. SpiderMonkey likes the second one first because anything else we do makes them more complicated.
• jdm: the JS classes are C++ classes that are designed to be inlined. If we write Rust wrappers that call them, we have performance penalties and we duplicate lots of stuff.
• jack: they have the usual operator overloading magic.
• brson: embed a C++ compiler in Rust! Yay!
• kmc: in order to use the current SpiderMonkey we need this support, right?
• jack: no, we can wrap it and export C stubs
• kmc: the C++ work potentially solves the other problem (proxies) as well
• jack: we consider the API bindings to include the... same situation we ran into while optimizing layout because the property accessors are FFI calls, which is too expensive relative to just grabbing pointers
• kmc: link-time optimization? Could we build the C++ code with clang?
• brson: I don't know to what extent that would be useful. We'd have to run tests.
• jack: I will follow up with SpiderMonkey. Maybe other ideas will come out.
• azita: need a short-term fix?
• jack: we can do one ourselves. The SpiderMonkey team (Bill) will accept our short-term fix into their codebase once they have some other stuff on their side stable. Our problem is that they are churning quickly, and we keep having to write code to try to keep up with them.
• azita: performance penalties?
• jack: not too concerned about SpiderMonkey performance penalties. We avoid it right now by duplicating the code in Rust. The code we're duplicating right now is not very good for this. bz said that nobody should be touching that code.
• azita: ....support....
• jack: so far, no problems working with them.

summit demo crashes

• jack: how are we looking?
• jdm: probably demo on OSX. lots of mesa problems.
• kmc: linux isn't bad with CPU rendering. but osx is probably the safer bet
• jack: is this new?
• lbergstrom: the summit demos have a lot more stuff going on
• kmc: longcat quickly becomes scattercat on linux. I'm not looking to fix that right now with the potential CPU fix
• jack: lars, have you found out anything about the pauses?
• lbergstrom: not convinced we're leaking, we just seem to be flooding the card. opengl profiler shows 500 copies of longcat bottom, if you shrink window it all seems to return to normal
• jack: that sounds like a bug
• kmc: DrawTargets and Textures stored in managed boxes e.g. in LayerBuffer and Quadtree, if we're relying on calling glDeleteTextures() etc. in destructor, maybe there's a cycle that's causing them to stick around. switching to owned pointers everyone agrees is what we want, but more work than can handle before friday
• lars: still see some crashes on osx on shutdown after lots of resizing

Memory leaks

• jack: kmc's patches for memory leaks landed today. We no longer triple-ref-count the drawtargets, so memory was never being released. if samsung wants to check again on android, might help with leak problems noticed before.

Work week

• azita: the work week was approved today. Ashley will book the hotel for us. Thanks for the list of hotels! Everyone should book their own flights for the week. She will put the hotel info in the wiki page. Book in the next couple of weeks (after summit would be good).
• kmc: can we get the address of the samsung office? I'd like to plan.
• azita: will put it on the wiki page.
• jack: I will create an etherpad for the logistics.
• azita: put it on the wiki to coordinate with Ashley
• azita: Andreas will be there for the beginning of the week. Can we set up the agenda for the week? The first day or two would be good for meetings beside technical discussions.
• azita: last time over e-mail you said that you need to check with executives.
• samsung: still checking with executives and overseas lab (?). Still scheduling our internal plans, so no agenda quite yet.
• azita: just want to make sure we don't miss the window. Andreas will only be in Monday and Tuesday for meetings with executives.
• samsung: will try to organize executive meetings for Monday or Tuesday.
• azita: we can continue the detailed agenda discussion over e-mail

Text shaping optimizations

• samsung: brief results. We were talking about text shaping. We looked at webkit and for simple text they use fast path character-by-character. We discussed last time and wanted to not bother doing the fast path, so we experimented with it. 50% performance increase using character-by-character processing.
• jack: Gecko does not do the optimization to get nicer looking text. Gecko does not parallelize it (as we could) but they do use a word cache for harfbuzz to keep the performance good. Any font that has space instead of ligatures never hits the cache, so there is a slow path there. We would like to have the nicer text rendering with parallelism and caching. These experiments will help us understand what the fastest we can do is.
• samsung: in WebKit they also only do shaping for words that are in the viewport. We do not do that - should we try that? If nobody is working on it, can we look at it?
• jack: nobody here is working on text shaping. Seth was working on it a while back, but I think that is done.
• samsung: Other microoptimizations, too, and will have results to share at the next meeting.
• samsung: Can dherman give a seminar when he visits? A technical talk to this group or to other employees.
• azita: yes. Once we have the agenda planned, we can arrange that.

Iframe problems

• samsung: iframe demos at the beginning of october?
• jack: yes, src/test/html/summit.html
• samsung: we tested performance increases for iframe. We found a bug when we launch the iframe.html testcase, it shows a broken screen or just text that says, "this browser does not support iframe." Do you have plans to fix it?
• jack: we were unaware of it. We support local, remote, and sandboxes iframes
• brson: this is on a webpage in the wild? Which page is it?
• jack: I thought it was the one in our tree.
• jdm: we have no testcases in our tree that tell us we don't support iframes, so probably a live site
• jack: what specific test case did you use?
• samsung: we will send it
• jack: create an issue and we will look at it
• lbergstrom: my changes for inline iframes and inline flows in blocks hasn't landed yet. there are still fixes to be done there.
• samsung: we will share the test case with you soon

Android

• jack: how is the android shell coming? We want to know because the release engineering team needs it so that we can test the android version on checkins.
• aydinkim: we have a shared library for it. Fabrice asked how he can compile on android and how to make the android APK. I answered that a few days ago. But android's packaging is not stable yet. We are scheduled to fix it and will let you know about this issue.
• samsung: the packaging works fine. We are trying to stabilize it a little more and then will push it to the main branch.
• aydinkim: one more issue for window. Servo uses glfw, but there is no Android point. Temporarily we are using the glut on Android, but we would like to discuss how to connect the window system to glfw.
• jack: It would be nice if we could just use egl directly. I know glfw has support for that, but we need to test what the alternative backends look like on android to see if we can settle on a single windowing system. So we need to experiment with that. Do you want to look into this? It's not the highest priority item right now because supporting glut and glfw is not too expensive right now.
• jack: did your removing yield work land? does glut cause any problems for that?
• lars: no, architecturally very similar. they all just block in teh msging loop.