Meeting 2013 10 28
Josh Matthews edited this page Oct 29, 2013
·
2 revisions
- note taking reminder
- OS X lowest supported version
- rustpkg status
- rust-http SSL support
- string interning patch
- draft seoul agenda (https://etherpad.mozilla.org/servo-in-seoul )
- retina display
- reflow performance
- Android compositing support
jack, kmc, lbergstrom, pcwalton, Azita, brson, Samsung
- J: Lars has been doing a lot of work note-taking. If others can help and/or correct errors then that would be much appreciated.
- J: A couple of people on the team have been on 10.6 for some time. pcwalton just updated to 10.8. Does anyone need 10.6?
- B: I am
- J: Do you plan to stay there?
- B: I'm flexible but don't intend to upgrade unless I have to
- J: Is there anyone else on 10.6? (silence)
- J: We'll leave the status quo in place but if GLFW breaks something on 10.6 we won't fix it unless it's trivial. Is that fine?
- B: OK
- J: After the epic Rust upgrade that we had, which was only done in order to get a new version of rustpkg, we can now continue to make progress on rustpkg. After doing the upgrade I resumed my rustpkg work because Keegan was interested in taking over that work. We ran into a rustpkg bug that was hopefully fixed earlier today—let me see if that landed—we need to upgrade again. We need to take another Rust upgrade.
- K: We need to rewrite our debug! macros.
- K: I'm happy to do the Rust upgrade as well
- P: Will also improve performance. Inline extra::arc. A lot of rendering time is spent there
- J: option API rename just landed.
- K: Since I'm not in the middle of anything big right now can I start on the next Rust upgrade right away?
- J: OK
- S: When will we upgrade Rust?
- J: Immediately. rustpkg builds 9 crates. Next small goal is to get glfw-rs ported. We want glfw to be a submodule of glfw-rs. Then we want rustpkg to build the C library. Supposedly it's capable of doing that. Assuming that works out we can start porting all of the things that build C libraries. We can get closer to having all of Servo to build with rustpkg.
- K: Which is really important to getting rustpkg feature complete for 1.0.
- J: rust-http just got a PR to do SSL. Unfortunately it uses rust-ssl which is OpenSSL and that is not suitable for us because it's not NSS and there are FIPS certification issues. I talked to ChrisMorgan about how to fix this. The hope is to do it with a trait.
- B: Can this go to rust-ssl and have the trait there, behind a configure switch?
- J: SSL is not on our immediate term plans.
- K: I'm skeptical of pluggable backends for this crypto stuff.
- P: I don't know if we have much of a choice.
- K: Who's pushing to use OpenSSL over NSS?
- J: Nobody was really pushing it. OpenSSL and GnuTLS are the de facto standards. Nobody knows about NSS. The use cases that we have as a browser vendor may be different for OpenSSL. I don't know what the best way forward here. Does anyone care about SSL implementations?
- sanxiyn: Doesn't NSS depend on NSPR? That could be a problem for some
- P: Crypto people say that Rust needs to use OpenSSL on the server and NSS on the client. I feel the trait is probably our best option; I know there could be security problems, but I think the alternatives are worse. Not using OpenSSL on the server is going to be weird, and using OpenSSL on the client is not an option.
- K: Why is that?
- P: I don't know for sure. I've always been told that NSS is a hard req. All browser use it (well, Chrome & Firefox) but I don't know why.
- P: Three options: use the trait, or make the server weird, or make the client weird. It's hard to know what the issues here are. Let's talk to some professionals about the differences. Both FIPS-certified (or are they not at the same level?). OpenSSL has a different API. Lots of auditing. But the original author (Adam Langley) went with NSS for Chrome.
- B: OpenSSL is incompatible with some licenses.
- J: MPL?
- B: Don't know.
- J: We'll mail licensing. Kmc can follow up with crypto folks. Those answers will let us know what we need to do.
- J: You were worried about hubbub. I think we can remove hubbub as a requirement, since we plan to remove it.
- S: There must be miscommunication about hubbub.
- J: Yes, the DOM stuff definitely does. I think it's reasonable to land the string interning patch without interning everything.
- S: The string interning should be task safe?
- J: Yes, that was the problem we had with libwcaplet. It had a big lock that slowed us down.
- K: lock-free hash table?
- P: Probably the best idea so far. And it should may be go into rust. Not libstd, but maybe an incubator / separate project. java.util.concurrent for Rust would be great.
- J: Can we boostrap this by doing RWArcs around a normal hash table?
- P: Yes.
- S: Using a lock instead of RWArc? We were taking the lock every time we interned a string. We could be more coarse, just grabbing the lock at the beginning of parse and dropping at the end.
- P: It will help in the short term, but will hurt when we have a parallel CSS selector matching.
- S: does CSS intern anything?
- P: No, you're right. Maybe it makes sense to just make the lock coarser.
- K: lock-free reads and locked writes? Parse in parallel and then intern everything?
- P: Maybe better to do something coarse for now to get it faster and in and do something more complicated later.
- J: Solve the thread-safe issue with coarse-grained locking or RWArc and land the patch. Then do lock-free hashing later.
- S: Sounds like a plan.
- J: Brian, we're going to explode libextra (in Rust). Should we do the same thing with lock-free hashtables?
- B: I like patrick's java.util.concurrent idea.
- J: Should we pull the libextra concurrent stuff and put it in here?
- B: Sure. Some of the libextra stuff might end up in something more general (e.g., Arcs)
- J: This is a first draft. Basic idea is that in the morning we would have 1-2 sessions for the general audience. There should be 15 Samsung people and 9 Mozilla, so 24 people. High-level discussions in the morning and then break into groups of 4-5 people each for the afternoon to work on those projects through the week. We would do that each day.
- J: For the session presentation stuff, I have topics and potential presentations there. I'm curious if there are specific things that Samsung would like to learn about or if Mozilla has things that we would like Samsung to present that we could list.
- A: Could we have a session just to talk about overall planning for the year? I think it would be good for the group to hear from both sides. Maybe as an intro on the first day? Maybe talk about both resourcing and what the plan for Servo is on both sides. The other thing is just to get clarification on what we need to prepare for the presentations. Dave Herman wanted to know what he should prepare. What level of detail should the Rust (and Servo) presentations be at?
- J: Don't have to figure it all now. Just wanted to get some general feedback so that over the next couple of weeks we could be as specific as possible.
- A: Comments from Samsung on the presentations now or soon would be appreciated. We only have a week and a half, and it takes time to put together the larger presentations.
- A: For the presentations that Jack has on the list (intro to rust and intro to servo), could you let us know what level of detail you are looking for? These are supposed to be for a Samsung general audience, we believe.
- B: I am specifically concerned about what kind of training we will have to do.
- A: We just need to know (possibly as a response to the e-mail) so that we can prepare the presentations.
- S: I will pass that on.
- J: The workweek agenda is in the etherpad because the internal Mozilla wiki is not available.
- A: Can we add all of the Samsung attendees as well?
- J: Yes, that would be great.
- S: We will put our names there.
- J: I will follow up for more information and the agenda.
- P: How do we want to fix it? I saw we have some code that queries for it. There is also stuff with CSS-unit. Will it be enough to have the compostior tell the constellation about it and have the engine scale everything up?
- J: We want it scaled up in different ways. In images, pixel-double. For text, we want to scale the font size by 2, but still render to the full amount of pixels. I was going to ask
- P: In the short term, we should change the Au that CSS reports.
- J: Wouldn't images be wrong?
- P: No, images don't come from the CSS file. The images come from the image-decode.
- J: Sounds right. I was going to talk to somebody on the graphics team in paris about how this is done in paris. css pixels, device pixels, layer pixels, and then (compositor?) pixels. Not sure how many we need of these, so I will follow up on that to find out what our strategy should be.
- P: I am pretty sure CSS needs to be changed because the definition of a pixel depends on retina display, so it makes sense that the Au should be changed.
- J: There were some blog posts about units in firefox; I will post them to the list. I agree that it is a really annoying problem. It made the Toronto demos annoying. Had to zoom, hit every race condition possible...
- P: Those are fixed except for some races with how we delete tiles. But we should be much better now. It's not anything we are doing wrong; it's just how we do things.
- P: It has been optimized. #1141 is the remaining issue, making text measure O(1). For block layout we are a little faster than gecko/webki at reflow. With measuring text, we are a little slower because of that bug. Not for the incremental case.
- P: Samsung, please let us know if these numbers help with our comparison with gecko and webkit. Please let us know if you have other things that you want us to focus on. But these are some early numbers that help.
- J: I would love for somebody else to reproduce those measurements.
- P: Please do - I can show you how to profile gecko / webkit.
- S: About reproducing the measurments. What testcase?
- P: A rainbow page, which I will check into the tree. I will send a PR by the end of the day so it can be shown.
- S: The performance test cases that we use should be in the repository.
- J: Does this work in stock firefox now?
- P: Do you mean does the page work?
- J: I mean, how are you getting the measurements?
- P: Just using Instruments. I am comparing the time spent in the Reflow() method. For webkit, using instruments against safari to measure the time spent in the layout() method.
- S: What is Instruments?
- P: Instruments.app, which is a dtrace application (profiler) for Mac OSX.
- J: Instruments is the profiler included with Xcode.
- S: How can we do a similar thing on linux?
- P: A perf tool will give you a call graph-based profiler on linux. On this page (and on several pages) we do one reflow, whereas webkit and gecko will do multiple reflows.
- J: Because gecko does an early reflow
- P: Yes, after parsing a certain amount of the page. At first I thought we were much slower, but found out we missed a couple of them.
- S: Isn't dtrace a entry/exit profiler?
- P: It should be sampling (or is on Mac)
- P: We have a recent change that affects compositing, allowing the renderer and compositor to run in separate processes. It will be nice for sandboxing and allow separate GL contexts. As a result, there are also a lot fewer crashes. But it is not clear to me how this will work on Android. After talking to the graphics team, this method relies on the ability to share textures between different GL contexts. IOSurface on Mac, XPixMap on Linux. EGL-based on android. Need to use EGLStream, but I'm not sure what the support is on Android drivers. We may need a fallback case that uses shared memory and texture upload on the compositor side. Can be straightforward, but is not implemented yet. If you want to forward-port the compositor changes to android, there is some work to be done.
- J: Spent about 6 hours talking about surface management. The problem with EGLStream is you get a texture out on the other side, so you can't share it. Comes up in Gecko because rendering to a texture and want to composite it, but might be taking a screenshot to show on the little tiles on the homescreen, so you need two copies. Two proposals. Simple one: surface pool (surface is a 2d grid of pixels) where the renderer will own the pool and you will give out a grid of pixels, you go through the steps, everybody has access, finite size to pool (with blocking), then detach the texture from the framebuffer, hand it to compositor (as pcwalton designed) when the refcount goes to zero, goes back to an azure draw target and then back to the system.
- P: need details
- J: will create a wiki page. In linux we do a gpu-gpu texture copy. Gecko does the same thing right now and is going to figure out how to avoid the problem on Linux. There is a trick to set what framebuffer 0, and then we can make it be one of those pixmaps. But this is an area that is really complicated in Gecko. They had several iterations of the design and in multi-process they have had to redo it twice again, so we should be careful to do a clean design from the start here.
- P: Now, no glcontext sharing whatsoever. Just abstract native graphics surface thing that you share.
- J: Only other piece to figure out is some way to get a GLContext from Linux on a releng machine, because we can't run contenttests. Even with the null compositor.
- P: did you try with the CPU rendering?
- K: in contenttest?
- P: with CPU rendering, there should be no GL context created.
- K: but in headless mode, the renderer does not run at all; the compositor is not initialized at all.
- J: It did not work, but I did not try to fix it.
- K: Did you return if headless mode is set?
- P: Not sure; we should check.
- J: Crashed on exit, but since we had so many other crashes in servo that we weren't checking the exit code anyway. There was probably a bug in the Rust library code related to
waitforpid. - P: File shutdown crashes again! There are now none known.
- K: I will go through the filed Issues to verify them.