Servo Meeting 2014-05-12

Reminder

Please update your status at: http://benjamin.smedbergs.us/weekly-updates.fcgi/

Agenda

work week update (jack)
Rust upgrade status (larsberg)
32bit build
Tradeoffs for HTML parser API design (kmc)
blog post ideas

Workweek

jack: Staying at the Benson hotel. Also will have a breakout room at the Portland office. I will send a draft agenda later this week for what we will work on while we are there.
azita: Hotel walking distance to office?
jack: Yes. It's walking distance to everything interesting in Portland.

Rust upgrade

lars: not much to say; we've had a lot of help from the community. ms2ger and manish have done a lot of the work getting it working on linux. most of the changes this time were fairly mechanical. that will bring us up to two days ago. may 10th.
azita: it's a lot of effort though right? you said it took a person full time?
lars: about a half a person continuously give or take.
jack: They're getting better...
lars: we're getting better at asking questions. alex warned me a few things were going to be broken. we're getting better about communicating with rust community.
brson: does the breaking changes log help now?
lars: not so much on this last one, but we expect it to help a ton in the next one. We'll let you know how helpful it is (or isn't).

32 bit build

jack: I have everything in for the 32-bit build for spidermonkey and Servo. Small changes, but the resulting binary is encountering a bug in the Rust ABI with 32-bit and C union types. We had a similar problem the first time we ported to Android. We worked around it there, but that workaround does not work in Linux. I have example code in C and Rust along with some IR to show what is going wrong. I need to file a Rust bug and bring it up in tomorrow's Rust meeting. I'm not sure what priority this should be. On the one hand, we have no high-priority 32-bit targets. We mainly wanted to fix the Android build's use of 32-bit SpiderMonkey. We also wanted the rr team to be able to use it against Servo, but rr is 32-bit only. Manish also has 32-bit machines, so it would help him greatly.
brson: If you have a small test case, I bet we can find somebody to help.
jack: It's not super-minimal, but I have it down to a single submodule so hopefully it is at least easy to reproduce.
brson: Alex believes we hvae a 32-bit x86 codegen bug. We are seeing intermittent crashes on 32-bit x86...
jack: Maybe a different manifestation of the same bug. The IR on 32-bit linux with the C-compiled thing calling into spidermonkey is a function call with byval, but the Rust one does not. There are other small differences, too, but I don't know if they matter...

HTML parser tradeoffs

kmc: Trying to find the HTML Tree Builder. It'll have a callback and not know about your dom. It needs a handle on your nodes (for the parser's internal state). Trying to make the parser usable outside of Servo, but not make it overly complicated or unsafe for the interaction between the parser and JS managed DOM. I was hoping to talk about priorities there. My view is that a little bit of unsafe code to interact with the JS managed DOM is ok, as long as we have a good reason why the things are safe. I would really like to make this project useful to other Rust projects.
jack: The unsafe code is only required for creating JS values? If I use the HTML parser with a different data structure, would I be able to do that without unsafe code?
kmc: The design is straightforward for a refcounted DOM. You can just clone them and pass them along. I will probably make a simple static parse tree based on refcounting or another trick. If you are not interested in using your own DOM type, the library will provide that.
jack: How much unsafe code for JS?
kmc: Still working on it. Two alternatives in the e-mail I sent. We can root every node when we create it and then pass around root objects, tearing it down at the end (simplest). Alternative is JS and rooting the parser itself, but will be much more complicated because the interface needs to know about JS, JSRef, and Temporary. I would rather not go that route and just have all the nodes rooted for the lifetime of the parser, only need unsafe code to make the lifetimes work out.
jack: I suggest if you put your example together with the refcounted structure and send it to jdm to have him work it for JS, then maybe he'll have some recommendations.
kmc: JS is also changing in the future (where the interior mutability is going). Not sure how it'd work.
jack: If we get usability outside of Servo with a little bit of unsafety, that's great. Today's is, I think, not only very unsafe but also totally unsound.
kmc: We also want to support on-thread and off-thread parsing, but I don't think that has ramifications in the API. Just build up the pending work and pass it to the script task.
jack: Is Manish's work on XHR blocked on this parser?
kmc: Why would it?
jack: Because of XMLResponse?
kmc: That needs an XML parser...
jack: It's HTML only?
kmc: Yes, I'm implementing the HTML5 syntax spec. Not sure for XHTML or XML in XHR. Probably a pretty separate parser. Despite the similarity, the HTML parser is much more complicated.
pcwalton: Webkit?
kmc: Gecko has a separate XML and HTML parser....
jack: Probably libxml, since it has xpat build in.
kmc: Someone will need XML in Rust soon enough. hopefully that will come along and we can just use it.
jack: If we need to make an XML parser, hopefully at least the design would be transferable.
kmc: The HTML parser is designed around the edge cases, so maybe not transferred to XML. I also think XHR does not often return XML.

Blog post ideas

jack: In a meeting with andreas, he'd like some more Mozilla Research-related blog posts. We should think about some stuff in Servo. Just wanted to bring it up in case anybody had ideas for stuff we should talk about and put on the research blog. Was thinking about the stuff comparing the parallelizability of foxnews, cnn, etc. If we're not ready to share info about gains we have gotten against other browsers, maybe just about the web in general. We'd like to share stuff for a more general audience.
pcwalton: That's not just good for external usage, those are numbers that we want to get anyway. We need to do some work in Servo to not crash on those pages, but I think that kind of study is not only great for PR (it will likely look good for us, based on our early numbers), but also it's just something we need to be doing as a group. Need to be more data-driven.
jack: Good for the linuxcon talk?
larsberg: Yes, though that is focusing on Mike's work on embedding.
kmc: Also could talk about how we integrate Rust's memory models with JavaScript. That is a hard technical problem, but could be very widely applicable.
jack: Yes, just talking about what Firefox does and what Webkit does and what we do, it'll help explain how we're trying to make memory leaks go away. Could also mention the oilpan work that google is trying to land.
kmc: Probably some other use cases outside of Servo, for how you make Rust work with an external memory system. Maybe drop a MPS garbage collector in.
jack: If we're lucky, we will also have some blog posts wrapping up the intern projects where we can also talk about their contributions. kmc, do you want to talk with jdm about a memory management post?
kmc: Will do.
jack: I'd like to spread them across the team, because these take a lot of time. Otherwise, we just get one blog post and then it's months before we see another one.
mbrubeck: Maybe when we hit an Android milestone. So far, even inside Mozilla, most people don't know that Servo runs on Android at all.
jack: It kinda walks slowly on android...
kmc: Maybe an ACID2 post? Here's what we found most difficult; here's a picture of the cake...
jack: We had a blog post, though no picture of the cake.

Graphics implementation azure/skia

Ryan: Graphic architecture of servo. Has Azure, skia, and opengles underneath. Is it possible to do opengl without going through azure and skia? What are the advantages of that?
pcwalton: We had a long thread internally on this with some members of the gecko graphics team. There is an advantage... not opengles directly (no way to do text). you'd still need a library on top of opengl. It could be a more direct layer than azure or skia. The biggest problem with azure/skia, it's an immediate mode API. For efficient use of GPU, you should use retained mode so that the hardware is not guessing if you will reuse glyphs or textures. That is where you want to handle resource questions as much as possible. Bas Schouten on our GFX team has thoughts about this. The library could be a generic library, but it needs a retained mode API and is something that would be good for web browsers in general. I don't think we can fully flush out the requirements in this meeting.
jack: When we brought this up, Bas and our VP Andreas have been wanting to do this for a while. It is probably a several person-years long work to rewrite that library, but for Servo we might be able to build only a smaller part of it. OpenGL also can't draw curves, so you can't do rounded corners... but Servo does not have rounded corners, so we might be able to create something quickly. We should talk to Bas about it. First, we will turn that internal thread into a mailing list thread.
zwarich: Much worse on mobile GPUs, especially for trying to stream glyphs. Most drivers do badly with it. At apple, we added our own OpenGL ES extensions that worked around it, but no such extension exists in a standard form. I'd be happy to contribute as well.
pcwalton: We have some support for that on Android (gralloc). There's no public API, but there are private APIs. We do the same thing on FFOS. Presumably, if you were to ship a browser on this... we might not need to write it off, because there are privileged APIs that enable these features.
jack: Memory use on Android was some of the motivation for this work. It showed where our memory usage was. It was over 70MB for spidermonkey, whereas azure/skia binaries were only 3. I'll move the internal discussion with Bas onto the mailing list, which will rope gw and zwarich in, since they have both done this work on apple and android. This would expand the scope of the Servo project, but I am pretty excited because Bas believed that we could build a much, much faster renderer.
zwarich: We will also have to support canvas at some point. We have to make sure that we can still have a canvas as fast as it currently is since they are also benchmarked.
jack: That's part of why we had azure in place right now. A school we were working with managed to map much of the canvas APIs to azure.
pcwalton: There is also Ejecta, which is a far more lightweight, but maybe not as fast as skia-gl.
jack: I'm not convinced - nobody has turned on skia-gl....
zwarich: CPU vs. GPU testing comes out more on retina/hidpi rather than mobile because the performance difference on mobile is narrower. With past experiences on iOS, disabling the 2D GPU renderer was usually a wash and sometimes a speedup. But safari on a macbook pro with CPU vs. GPU, the GPU renderer really shows up faster. So, if your GPU mode on a HIDPI is not faster than the CPU, there is definitely something wrong with your GPU backend.
jack: I think at Samsung you could replace the renderer task bits. We don't care how we go from display list to texture. You could just replace the way that the texture is made.
pcwalton: yes, it's nice that the display list is used by all of the engine. You just have to change how you interpret the display list commands (I think we only have 4). Three are trivial, but one is text.
kmc: Could try porting some of the display list items to GL calls...
jack: You mean do all the display lists on the GPU except for the text, and then do the text on the CPU and upload as a texture?
kmc: yes