1

Meeting 2014 02 24

Josh Matthews edited this page 2014-02-24 11:01:17 -08:00

Table of Contents

• Servo Meeting 2014-02-24
• Agenda
• Attending
• Embedding
• Son of JSManaged
• Rust upgrade
• PRs
• recruiting

Servo Meeting 2014-02-24

Agenda

• CEF's GTK dependency and layering in Servo (zmike)
• Son of JSManaged
• Rust upgrade: maybe do submodules in repos instead of in forked repo? (larsberg)
• Recruiting note: help source senior people in content & systems areas

Attending

pcwalton, jdm, larsberg, jack, zmike, ms2ger, kmc, SimonSapin, azita, brson

Embedding

• zmike: Working on the embedding (getting CEF online for Servo). Realized that CEF uses GTK internally. Applications expect to get these objects, which seemed like a stumbling point. pcwalton advised creation of those GTK objects ourselves and exporting them to the framework. Within a couple of weeks / next month, it shoudl be rendering.
• jack: platform-specific? GTK on linux only?
• zmike: Yes. I can do the Linux ones, but I can't do the others.
• jack: Patrick or I can do the CoreFoundation stuff on the Mac side.
• pcwalton: I think it's good to have GTK support because people like having a control they can put in their application. I think teh Webkit2 embedding also exposes GTK objects and the Mac version exposes Cocoa objects, so it's probably inevitable.
• zmike: One other aspect is that I will need some kind of rendering export thing separate from the current one so I can just dump data into a GTK window. I can bring that up on IRC when the time comes and I'm ready to do some rendering.
• jack: Can GTK windows show a texture? Can we just give it an OpenGL area?
• pcwalton: GTK OpenGLView
• jack: Then you don' tneed an export; can just hand it the texture that comes out of the compositor.
• pcwalton: Yes, there's a GTK GL extension.
• jack: Instead of making GTKWindow the default object, use GTKGLWindow (or whatever the equivalent is).
• zmike: We sort of have to do whatever CEF does, which is just a GTK Window. I'll have to explore it more...
• jack: Hopefully we can subclass those things (maybe GTKGLWindow is a subclass of GTKWIndow)?
• pcwalton: Can take any GTK widget and give it a GL capability. So, just return a GTK widget with a GTK GL capability and it's fine.
• zmike: I'll go down that path. Hopefully it just works :-)

Son of JSManaged

• jdm: JSManaged will be landing right after this meeing. BIG DEAL!
• jack: Does that mean no @muts in servo?
• jdm: I think so. Maybe not Page? Just that one.
• larsberg: Script is the only one left!
• jack: So just that, then. Anything else to know about JSManaged beyond the workweek demo?

Rust upgrade

• jack: What will get us? Temporary rvalue will help...
• pcwalton: New hash will help us on the perf front. If you get this weekend's build for selector matching.
• jack: Usually they take long enough that we'll get a newer one partway through. We've also always found rust bugs, so we'll probably get to pick that up.
• jdm: Getting rid of the vector matching pattern stuff? Did that happen?
• jack: Yes, but we can still match on slices, so we should be OK (trivial workaround). Just call .as_slice and match on that instead. Do we use other stuff?
• lars: i was going to suggest we push submodule changes to a branch on the main submodule repo so that it's easier for other people to pick up submodule changes.
• kmc: I'm fine with that, though it's also not that hard to do the foreach for the repos.
• jack: I'm OK with a push to the main repo. Name it with the date e.g. rust_upgrade_20140224. The 12/29 landed like 1/07 or so :-)
• jdm: With JSManaged, be aware that in Rust we've moved away from box representations of things, but there are lots of places in the script crate where we make assumptions that things are represented in boxes. Because with JSManaged, we needed to enforce that things are in boxes even if they do not require them, so everything contains a box under the hood.
• jack: And tydesc_box is gone in the new Rust?
• jdm: With the upgrade, there's a change that has gone in that makes it so that unique pointers to objects with boxes no longer force the unique pointer to be represented with a box. Once remove @-pointers everywhere, though, it will remove that requirement.
• kmc: Do you mean @-box with a linked-list of allocations and refcount and stuff? Yes, I believe they're getting rid of @-box entirely.
• jack: We import it from std::priv and such... hrm, that sound scary. Hopefully it won't bite us too badly.
• larsberg: I'll be counting on you for that, jdm.
• jack: What needs it?
• jdm: Everything! Some things.... hrm.

PRs

• jack: Lots of them in the queues! Anyone have something to talk about with one of those?
• jdm: Vtables. I would like feedback on the perf aspects of it. Right now, to make it easier to write the code for cases where you don't have specializations, it does one extra virtual call for each level of the hierarchy. Thoughts there would be useful.
• pcwalton: I will take a look.
• jack: Case where you have a JS base class and call a method on it and it's got to do the right thing?
• jdm: Or implementing afterSetAddr or something. Make it possible to override the default behavior at any level and call the parent type's overridden behavior ala C++.
• jack: An example of what that looks like after this patch?
• jdm: There's an example in the code where we call afterSetAddr, for example. Call getVTable for Then call the method on that vtable trait. It's quite lovely.
• larsberg: This is also for OnClick and OnHover?
• jdm: Yes, the .handleEvent stuff is where that should go.
• jack: I see the virtual ones... we call supertype.map.afterSetAddr for each supertype?
• jdm: It's a virtual method that gives an optional trait reference to the parent type. Makes it easy to not have to write implementations for every class in the hierarchy everywhere, but it does kind of give really bad performance.
• jack: So, there's a lot of supertype afterSetAddr calling all the way up the chain?
• jdm: Yes. Not the prettiest thing.
• jack: Is this faster in c++?
• jdm: I assume so? It knows the parent type concretely. We could explictily call it on our known parent type instead. But that requires writing the dispatch by hand for everything everywhere.
• jack: I guess we could generate it...
• jdm: The problem is then either write an implementation everywhere and always call it or have to indicate when we have a non-default implementation that we will write by hand. Somewhere.
• jack: That seems right up your alley, Patrick...
• pcwalton: I'll look at how to make that better!
• larsberg: Two student projects?
• jdm: One I haven't heard from; the other I haven't. I will ping them, might rebase them myself.

recruiting

• jack: Have some good candidates in the pipe. At least five. But we need more candidates! Especially on the Platform/systems front. Make sure to let larsberg or me know about potential candidates.